[opensuse-virtual] can't boot opensuse 13.2 + xen 4.5 on GRUB2/UEFI server. No console output & stall at initrd.
I've installed an openSUSE 13.2 server. The server's built on a modern Supermicro motherboard with full UEFI support. openSUSE boots ok via GRUB2+UEFI to kernel-default. uname -r 3.19.2-3.gd8856ce-default I'm working on the switch to a Xen Dom0 I installed efibootmgr-0.6.0-3.2.2.x86_64 grub2-x86_64-efi-2.02~beta2-20.5.1.x86_64 grub2-x86_64-xen-2.02~beta2-20.5.1.x86_64 kernel-xen-3.19.2-3.1.gd8856ce.x86_64 xen-4.5.0_03-359.6.x86_64 xen-libs-4.5.0_03-359.6.x86_64 xen-tools-4.5.0_03-359.6.x86_64 When I boot/select the Xen option it stalls at WARNING: no console will be available to os ... loading initramd ... There's no console output. A search on the message led me to http://lists.xenproject.org/archives/html/xen-users/2014-03/msg00142.html It is not possible to boot EFI Xen via grub. You should instead boot it direct from the EFI shell. http://xenbits.xen.org/docs/unstable/misc/efi.html has some documentation for the config file which Xen expects when booting in this mode. Daniel Kiper is working with grub upstream to make a version of multiboot which is compatible with EFI for use when booting Xen via grub on such systems. AFAIK it is not complete. and http://xenbits.xen.org/docs/unstable/misc/efi.html When booted as an EFI application, Xen requires a configuration file as described below unless a bootloader, such as GRUB, has loaded the modules and describes them in the device tree provided to Xen. If a bootloader provides a device tree containing modules then any configuration files are ignored, and the bootloader is responsible for populating all relevant device tree nodes. I'm not sure if those are relevant to this case. Does opensuse Xen Dom0 boot from GRUB2+UEFI? What/where do I need to edit to fix the 'no console' error? LT -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-virtual+owner@opensuse.org
On 26.03.15 at 08:17, <lyndat3@your-mail.com> wrote: I've installed an openSUSE 13.2 server.
The server's built on a modern Supermicro motherboard with full UEFI support.
openSUSE boots ok via GRUB2+UEFI to kernel-default.
uname -r 3.19.2-3.gd8856ce-default
I'm working on the switch to a Xen Dom0
I installed
efibootmgr-0.6.0-3.2.2.x86_64 grub2-x86_64-efi-2.02~beta2-20.5.1.x86_64 grub2-x86_64-xen-2.02~beta2-20.5.1.x86_64 kernel-xen-3.19.2-3.1.gd8856ce.x86_64 xen-4.5.0_03-359.6.x86_64 xen-libs-4.5.0_03-359.6.x86_64 xen-tools-4.5.0_03-359.6.x86_64
When I boot/select the Xen option it stalls at
WARNING: no console will be available to os ... loading initramd ...
There's no console output.
A search on the message led me to
http://lists.xenproject.org/archives/html/xen-users/2014-03/msg00142.html
It is not possible to boot EFI Xen via grub. You should instead boot it direct from the EFI shell.
http://xenbits.xen.org/docs/unstable/misc/efi.html has some documentation for the config file which Xen expects when booting in this mode.
Daniel Kiper is working with grub upstream to make a version of multiboot which is compatible with EFI for use when booting Xen via grub on such systems. AFAIK it is not complete.
and
http://xenbits.xen.org/docs/unstable/misc/efi.html
When booted as an EFI application, Xen requires a configuration file as described below unless a bootloader, such as GRUB, has loaded the modules and describes them in the device tree provided to Xen. If a bootloader provides a device tree containing modules then any configuration files are ignored, and the bootloader is responsible for populating all relevant device tree nodes.
I'm not sure if those are relevant to this case.
It is, in a way.
Does opensuse Xen Dom0 boot from GRUB2+UEFI?
I suppose so, but using the chainloader command, not the "normal" mechanism to invoke a multiboot aware OS. I would have thought that you even get respective entries created when installing Xen, which you could then at least use as reference. The chainloader mechanism of course requires using xen.efi, not xen.gz. (To be precise, booting xen.gz to "normal" way is possible on some systems - the main prerequisite is that despite there being UEFI the firmware also exposes ACPI tables such that they can be found without using EFI mechanisms.)
What/where do I need to edit to fix the 'no console' error?
No idea. Jan -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-virtual+owner@opensuse.org
I'm not sure if those are relevant to this case.
It is, in a way.
Does opensuse Xen Dom0 boot from GRUB2+UEFI?
I suppose so, but using the chainloader command, not the "normal" mechanism to invoke a multiboot aware OS. I would have thought that you even get respective entries created when installing Xen, which you could then at least use as reference. The chainloader mechanism of course requires using xen.efi, not xen.gz.
(To be precise, booting xen.gz to "normal" way is possible on some systems - the main prerequisite is that despite there being UEFI the firmware also exposes ACPI tables such that they can be found without using EFI mechanisms.)
Reading http://wiki.xenproject.org/wiki/Xen_EFI Xen 4.3 and later can be built as EFI binaries. Xen 4.5 can be built as an EFI binary under ARM. Linux 3.17 and later when built with CONFIG_XEN_EFI can be booted under Xen in EFI platform. Checking the prereqs I did find the EFI binary find / | grep xen.efi /usr/lib64/efi/xen.efi rpm -q --whatprovides /usr/lib64/efi/xen.efi xen-4.5.0_03-359.6.x86_64 Reading, the kernel's been patched to check for using the CONFIG_XEN_EFI flag Put EFI machinery for Xen in place http://markmail.org/message/3zumxhat4trjkaeu Checking for it, it's missing from the installed Xen kernel's config grep -i efi /boot/config-3.19.2-3.gd8856ce-xen CONFIG_EFI_PARTITION=y CONFIG_EFI=y CONFIG_EFI_STUB=y # Software defined radio USB devices CONFIG_FB_EFI=y CONFIG_RTC_DRV_EFI=m CONFIG_DMI_SCAN_MACHINE_NON_EFI_FALLBACK=y # EFI (Extensible Firmware Interface) Support CONFIG_EFI_VARS=m CONFIG_EFI_VARS_PSTORE=m # CONFIG_EFI_VARS_PSTORE_DEFAULT_DISABLE is not set CONFIG_UEFI_CPER=y CONFIG_CACHEFILES=m # CONFIG_CACHEFILES_DEBUG is not set # CONFIG_CACHEFILES_HISTOGRAM is not set CONFIG_EFIVAR_FS=m IIUC it's required. Is there an available kernel for openSUSE with that flag? Also it looks like direct grub2 booting of xen.gz as ELF binary is deferred until Xen 4.6 Xen as gz binary GRUB2 loader when built as an EFI binary can load various OS-es. The most common one is Linux where it uses the linuxefi GRUB module. However GRUB2 also has support for multiboot protocol which is what Xen uses. Sadly v1 of multiboot API does not have enough data to provide information to Xen under the EFI platform. As such a [[5]proposal] had been discussed to add a multibootv2+EFI API which would provide enough data such that GRUB2's multiboot module could pass that to Xen compiled as ELF binary (.gz). This would allow: EFI firmware => GRUB2.EFI -> multiboot2 -> [xen.gz, vmlinuz, ramdisk] And GRUB2 would be responsible for reading from the ESP the various files and loading them in the memory. That work has been deferred to Xen 4.6. unless there's been more recent progress, either at opensuse or upstream. Does opensuse's Xen 4.5 support the xen.gz booting *now*? If not, the mentioned chainloading appears to be the alternative The provided GRUB2 chainloader example @ Xen upstream is: menuentry "Xen EFI" { insmod part_gpt insmod search_fs_uuid insmod chain chainloader (hd0,gpt1)/EFI/XEN/xen.efi } I didn't find any example or mention in the opensuse install. Yet. You mentioned that direct 'normal' booting of the xen.gz might be possible with sufficient exposure of the acpi tables. I'm not sure how to check. The related dmesg output while booting the -default kernel is dmesg | grep -i acpi [ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-3.19.2-3.gd8856ce-default root=UUID=4753623b-a7c2-2cc6-a9de-72171b816057 ro splash=silent noresume showopts noquiet nomodeset vga=0x034c clocksource=acpi_pm divider=10 pcie_aspm=off systemd.log_target=journal-or-kmsg systemd.log_level=info loglevel=info [ 0.000000] BIOS-e820: [mem 0x000000008daee000-0x000000008daf4fff] ACPI NVS [ 0.000000] BIOS-e820: [mem 0x000000009e8a1000-0x000000009e9cffff] ACPI NVS [ 0.000000] reserve setup_data: [mem 0x000000008daee000-0x000000008daf4fff] ACPI NVS [ 0.000000] reserve setup_data: [mem 0x000000009e8a1000-0x000000009e9cffff] ACPI NVS [ 0.000000] efi: ACPI 2.0=0x9e9a5000 ACPI=0x9e9a5000 SMBIOS=0xf04c0 MPS=0xfd490 [ 0.000000] efi: mem18: [ACPI Memory NVS | | | | | |WB|WT|WC|UC] range=[0x000000008daee000-0x000000008daf5000) (0MB) [ 0.000000] efi: mem89: [ACPI Memory NVS | | | | | |WB|WT|WC|UC] range=[0x000000009e8a1000-0x000000009e9bd000) (1MB) [ 0.000000] efi: mem90: [ACPI Memory NVS | | | | | |WB|WT|WC|UC] range=[0x000000009e9bd000-0x000000009e9cc000) (0MB) [ 0.000000] efi: mem91: [ACPI Memory NVS | | | | | |WB|WT|WC|UC] range=[0x000000009e9cc000-0x000000009e9d0000) (0MB) [ 0.000000] ACPI: Early table checksum verification disabled [ 0.000000] ACPI: RSDP 0x000000009E9A5000 000024 (v02 SUPERM) [ 0.000000] ACPI: XSDT 0x000000009E9A5098 0000B4 (v01 SUPERM SMCI--MB 01072009 AMI 00010013) [ 0.000000] ACPI: FACP 0x000000009E9B0BB8 00010C (v05 SUPERM SMCI--MB 01072009 AMI 00010013) [ 0.000000] ACPI: DSDT 0x000000009E9A51E8 00B9C9 (v02 SUPERM SMCI--MB 00000000 INTL 20120711) [ 0.000000] ACPI: FACS 0x000000009E9CFF80 000040 [ 0.000000] ACPI: APIC 0x000000009E9B0CC8 000072 (v03 SUPERM SMCI--MB 01072009 AMI 00010013) [ 0.000000] ACPI: FPDT 0x000000009E9B0D40 000044 (v01 SUPERM SMCI--MB 01072009 AMI 00010013) [ 0.000000] ACPI: SSDT 0x000000009E9B0D88 000BEE (v01 Ther_R Ther_Rvp 00001000 INTL 20120711) [ 0.000000] ACPI: SSDT 0x000000009E9B1978 000539 (v01 PmRef Cpu0Ist 00003000 INTL 20051117) [ 0.000000] ACPI: SSDT 0x000000009E9B1EB8 000B74 (v01 CpuRef CpuSsdt 00003000 INTL 20051117) [ 0.000000] ACPI: SSDT 0x000000009E9B2A30 0002DE (v01 PmRef Cpu0Tst 00003000 INTL 20051117) [ 0.000000] ACPI: SSDT 0x000000009E9B2D10 000348 (v01 PmRef ApTst 00003000 INTL 20051117) [ 0.000000] ACPI: MCFG 0x000000009E9B3058 00003C (v01 SUPERM SMCI--MB 01072009 MSFT 00000097) [ 0.000000] ACPI: HPET 0x000000009E9B3098 000038 (v01 SUPERM SMCI--MB 01072009 AMI. 00000005) [ 0.000000] ACPI: SSDT 0x000000009E9B30D0 000397 (v01 SataRe SataTabl 00001000 INTL 20120711) [ 0.000000] ACPI: SSDT 0x000000009E9B3468 005B5E (v01 SaSsdt SaSsdt 00003000 INTL 20120711) [ 0.000000] ACPI: ASF! 0x000000009E9B8FC8 0000A5 (v32 INTEL HCG 00000001 TFSM 000F4240) [ 0.000000] ACPI: DMAR 0x000000009E9B9070 000080 (v01 INTEL BDW 00000001 INTL 00000001) [ 0.000000] ACPI: EINJ 0x000000009E9B90F0 000130 (v01 AMI AMI EINJ 00000000 00000000) [ 0.000000] ACPI: ERST 0x000000009E9B9220 000230 (v01 AMIER AMI ERST 00000000 00000000) [ 0.000000] ACPI: HEST 0x000000009E9B9450 0000A8 (v01 AMI AMI HEST 00000000 00000000) [ 0.000000] ACPI: BERT 0x000000009E9B94F8 000030 (v01 AMI AMI BERT 00000000 00000000) [ 0.000000] ACPI: Local APIC address 0xfee00000 [ 0.000000] ACPI: PM-Timer IO Port: 0x1808 [ 0.000000] ACPI: Local APIC address 0xfee00000 [ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1]) [ 0.000000] ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0]) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) [ 0.000000] ACPI: IRQ0 used by override. [ 0.000000] ACPI: IRQ9 used by override. [ 0.000000] Using ACPI (MADT) for SMP configuration information [ 0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000 [ 0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-3.19.2-3.gd8856ce-default root=UUID=4753623b-a7c2-2cc6-a9de-72171b816057 ro splash=silent noresume showopts noquiet nomodeset vga=0x034c clocksource=acpi_pm divider=10 pcie_aspm=off systemd.log_target=journal-or-kmsg systemd.log_level=info loglevel=info [ 0.000030] ACPI: Core revision 20141107 [ 0.014758] ACPI: All ACPI Tables successfully acquired [ 0.126607] PM: Registering ACPI NVS region [mem 0x8daee000-0x8daf4fff] (28672 bytes) [ 0.126610] PM: Registering ACPI NVS region [mem 0x9e8a1000-0x9e9cffff] (1241088 bytes) [ 0.135861] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it [ 0.135863] ACPI: bus type PCI registered [ 0.135865] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 [ 0.139992] ACPI: Added _OSI(Module Device) [ 0.139994] ACPI: Added _OSI(Processor Device) [ 0.139995] ACPI: Added _OSI(3.0 _SCP Extensions) [ 0.139996] ACPI: Added _OSI(Processor Aggregator Device) [ 0.143181] ACPI: Executed 5 blocks of module-level executable AML code [ 0.147105] ACPI: Dynamic OEM Table Load: [ 0.147111] ACPI: SSDT 0xFFFF88083940B400 0003D3 (v01 PmRef Cpu0Cst 00003001 INTL 20051117) [ 0.147741] ACPI: Dynamic OEM Table Load: [ 0.147745] ACPI: SSDT 0xFFFF880839410000 0005AA (v01 PmRef ApIst 00003000 INTL 20051117) [ 0.148419] ACPI: Dynamic OEM Table Load: [ 0.148423] ACPI: SSDT 0xFFFF880839412400 000119 (v01 PmRef ApCst 00003000 INTL 20051117) [ 0.149394] ACPI: Interpreter enabled [ 0.149400] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S1_] (20141107/hwxface-580) [ 0.149406] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S2_] (20141107/hwxface-580) [ 0.149420] ACPI: (supports S0 S3 S4 S5) [ 0.149422] ACPI: Using IOAPIC for interrupt routing [ 0.149471] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug [ 0.149843] ACPI: Power Resource [PG00] (on) [ 0.150257] ACPI: Power Resource [PG01] (on) [ 0.150738] ACPI: Power Resource [PG02] (on) [ 0.157303] ACPI: Power Resource [FN00] (off) [ 0.157372] ACPI: Power Resource [FN01] (off) [ 0.157439] ACPI: Power Resource [FN02] (off) [ 0.157505] ACPI: Power Resource [FN03] (off) [ 0.157571] ACPI: Power Resource [FN04] (off) [ 0.158366] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-7e]) [ 0.158371] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig Segments MSI] [ 0.158538] acpi PNP0A08:00: _OSC: not requesting OS control; OS requires [ExtendedConfig ASPM ClockPM MSI] [ 0.159465] pci 0000:00:01.0: System wakeup disabled by ACPI [ 0.159575] pci 0000:00:01.1: System wakeup disabled by ACPI [ 0.159684] pci 0000:00:01.2: System wakeup disabled by ACPI [ 0.159862] pci 0000:00:14.0: System wakeup disabled by ACPI [ 0.160348] pci 0000:00:19.0: System wakeup disabled by ACPI [ 0.160548] pci 0000:00:1a.0: System wakeup disabled by ACPI [ 0.160711] pci 0000:00:1b.0: System wakeup disabled by ACPI [ 0.160858] pci 0000:00:1c.0: System wakeup disabled by ACPI [ 0.161001] pci 0000:00:1c.1: System wakeup disabled by ACPI [ 0.161145] pci 0000:00:1c.3: System wakeup disabled by ACPI [ 0.161297] pci 0000:00:1c.4: System wakeup disabled by ACPI [ 0.161500] pci 0000:00:1d.0: System wakeup disabled by ACPI [ 0.162234] pci 0000:01:00.0: System wakeup disabled by ACPI [ 0.162430] pci 0000:02:00.0: System wakeup disabled by ACPI [ 0.162747] pci 0000:03:00.0: System wakeup disabled by ACPI [ 0.163025] pci 0000:04:00.0: System wakeup disabled by ACPI [ 0.163304] pci 0000:05:00.0: System wakeup disabled by ACPI [ 0.168709] pci 0000:10:00.0: System wakeup disabled by ACPI [ 0.168821] acpiphp: Slot [1] registered [ 0.169619] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 10 *11 12 14 15) [ 0.169687] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 *10 11 12 14 15) [ 0.169752] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 10 11 12 14 15) [ 0.169818] ACPI: PCI Interrupt Link [LNKD] (IRQs *3 4 5 6 10 11 12 14 15) [ 0.169880] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 10 *11 12 14 15) [ 0.169940] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled. [ 0.170004] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 *10 11 12 14 15) [ 0.170064] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 *5 6 10 11 12 14 15) [ 0.170336] ACPI: Enabled 7 GPEs in block 00 to 3F [ 0.170553] PCI: Using ACPI for IRQ routing [ 0.179796] pnp: PnP ACPI init [ 0.179901] system 00:00: Plug and Play ACPI device, IDs PNP0c01 (active) [ 0.179984] system 00:01: Plug and Play ACPI device, IDs PNP0c02 (active) [ 0.180012] pnp 00:02: Plug and Play ACPI device, IDs PNP0b00 (active) [ 0.180050] system 00:03: Plug and Play ACPI device, IDs INT3f0d PNP0c02 (active) [ 0.180162] system 00:04: Plug and Play ACPI device, IDs PNP0c02 (active) [ 0.180415] pnp 00:05: Plug and Play ACPI device, IDs PNP0501 (active) [ 0.180466] system 00:06: Plug and Play ACPI device, IDs PNP0c02 (active) [ 0.180823] system 00:07: Plug and Play ACPI device, IDs PNP0c02 (active) [ 0.181020] pnp: PnP ACPI: found 8 devices [ 0.187340] Switched to clocksource acpi_pm [ 2.131474] ata6.00: ACPI cmd ef/10:06:00:00:00:00 (SET FEATURES) succeeded [ 2.131476] ata6.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE LOCK) filtered out [ 2.132612] ata6.00: ACPI cmd b1/c1:00:00:00:00:00 (DEVICE CONFIGURATION OVERLAY) filtered out [ 2.133783] ata5.00: ACPI cmd ef/10:06:00:00:00:00 (SET FEATURES) succeeded [ 2.133785] ata5.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE LOCK) filtered out [ 2.134981] ata5.00: ACPI cmd b1/c1:00:00:00:00:00 (DEVICE CONFIGURATION OVERLAY) filtered out [ 2.589279] ata6.00: ACPI cmd ef/10:06:00:00:00:00 (SET FEATURES) succeeded [ 2.589285] ata6.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE LOCK) filtered out [ 2.589289] ata6.00: ACPI cmd b1/c1:00:00:00:00:00 (DEVICE CONFIGURATION OVERLAY) filtered out [ 2.590716] ata5.00: ACPI cmd ef/10:06:00:00:00:00 (SET FEATURES) succeeded [ 2.590719] ata5.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE LOCK) filtered out [ 2.590722] ata5.00: ACPI cmd b1/c1:00:00:00:00:00 (DEVICE CONFIGURATION OVERLAY) filtered out [ 3.760562] ACPI: Thermal Zone [TZ00] (28 C) [ 3.763264] ACPI: bus type USB registered [ 3.768341] ACPI: Thermal Zone [TZ01] (30 C) [ 22.541598] ACPI: Sleep Button [SLPB] [ 22.544369] ACPI: Power Button [PWRB] [ 22.547275] ACPI: Power Button [PWRF] The line ACPI: All ACPI Tables successfully acquired suggests 'completeness' of some kind. With this info is 'normal' booting of kernel-xen/Xen on this system possible? LT -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-virtual+owner@opensuse.org
On 26.03.15 at 15:14, <lyndat3@your-mail.com> wrote: Does opensuse Xen Dom0 boot from GRUB2+UEFI?
I suppose so, but using the chainloader command, not the "normal" mechanism to invoke a multiboot aware OS. I would have thought that you even get respective entries created when installing Xen, which you could then at least use as reference. The chainloader mechanism of course requires using xen.efi, not xen.gz.
(To be precise, booting xen.gz to "normal" way is possible on some systems - the main prerequisite is that despite there being UEFI the firmware also exposes ACPI tables such that they can be found without using EFI mechanisms.)
Reading
http://wiki.xenproject.org/wiki/Xen_EFI
Xen 4.3 and later can be built as EFI binaries. Xen 4.5 can be built as an EFI binary under ARM.
Linux 3.17 and later when built with CONFIG_XEN_EFI can be booted under Xen in EFI platform.
Checking the prereqs I did find the EFI binary
find / | grep xen.efi /usr/lib64/efi/xen.efi rpm -q --whatprovides /usr/lib64/efi/xen.efi xen-4.5.0_03-359.6.x86_64
Reading, the kernel's been patched to check for using the CONFIG_XEN_EFI flag
Put EFI machinery for Xen in place http://markmail.org/message/3zumxhat4trjkaeu
That's for the pv-ops kernel, not ours.
Checking for it, it's missing from the installed Xen kernel's config
grep -i efi /boot/config-3.19.2-3.gd8856ce-xen CONFIG_EFI_PARTITION=y CONFIG_EFI=y
This line is what's relevant in our kernel.
Also it looks like direct grub2 booting of xen.gz as ELF binary is deferred until Xen 4.6
Right, in its full form (i.e. when ACPI tables can only be acquired using EFI data).
You mentioned that direct 'normal' booting of the xen.gz might be possible with sufficient exposure of the acpi tables.
I'm not sure how to check. The related dmesg output while booting the -default kernel is
This doesn't mean anything. You would only know by checking the respective log of kernel-xen when booted with xen.gz. Jan -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-virtual+owner@opensuse.org
That's for the pv-ops kernel, not ours.
I don't have a good handle on all the differences. I did stumble on http://wiki.xenproject.org/wiki/XenParavirtOps/OpenSUSE which appears to detail some.
grep -i efi /boot/config-3.19.2-3.gd8856ce-xen CONFIG_EFI_PARTITION=y CONFIG_EFI=y
This line is what's relevant in our kernel.
Then that sounds like it's sufficient for this case
I'm not sure how to check. The related dmesg output while booting the -default kernel is
This doesn't mean anything. You would only know by checking the respective log of kernel-xen when booted with xen.gz.
Since I can't boot to kernnel-xen, Catch22. Unless I've missed your meaning, it looks like the only option for now is to chainload the xen.efi. LT -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-virtual+owner@opensuse.org
On 26.03.15 at 15:58, <lyndat3@your-mail.com> wrote: This doesn't mean anything. You would only know by checking the respective log of kernel-xen when booted with xen.gz.
Since I can't boot to kernnel-xen, Catch22.
Without having seen the log thereof, it's hard to say if you really can't. Did you attach a serial console? If not, does Xen itself print anything to the screen when you pass it "console=vga"? Jan -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-virtual+owner@opensuse.org
This doesn't mean anything. You would only know by checking the respective log of kernel-xen when booted with xen.gz.
Since I can't boot to kernnel-xen, Catch22.
Without having seen the log thereof, it's hard to say if you really can't. Did you attach a serial console?
I attached and tried to set it up. So far no luck getting any output at all. On my todo list.
If not, does Xen itself print anything to the screen when you pass it "console=vga"?
I'm aleady passing GRUB_CMDLINE_XEN=" ... vga=gfx-1280x1024x16 com1=57600,8n1,pci console=com1,vga ... " which was sufficient on a pre-UEFI, pre-Grub2 system. Currently, on console I get only to WARNING: no console will be available to os ... loading initramd ... and no farther. -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-virtual+owner@opensuse.org
participants (2)
-
Jan Beulich -
lyndat3＠your-mail.com