similar to: Bug#703586: Slight mistake in version difference

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

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.000000] ACPI: RSDP 00000000000f0010 000024 (v02 SUPERM) I?m running this on a

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

On Wed, 10 Sep 2014 20:22:54 +0100 Ian Campbell <ijc at 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) > >

On Sun, 2014-09-07 at 00:02 +0200, John Keates wrote: > 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, What is "pep"? > and a tiny bit of infrastructure to get xen.efi, vmlinuz, an initrd > and a xen.cfg on to the ESP partition and letting

On Sat, 2014-09-13 at 17:00 +0200, John Keates wrote: > 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. >

Hi, It seems on Jessie it?s not possible to turn off tx checksum offloading to netfront right now, which is problematic if you have any form of firewall or NAT between your DomU and WAN? Is this a know regression? Running on kernel 3.16 ethtool -K eth0 tx off complains it cannot change anything, on kernel 3.2 it turns off tx checksumming successfully, both using xen_netfront. Using a virtualised

close 703586 4.4.1-3 On Sun, Sep 14, 2014 at 04:55:41PM +0100, Ian Campbell wrote: > On Sat, 2014-09-13 at 17:00 +0200, John Keates wrote: > > But having xen.efi in the package would be a ton of help already. Who > > do I stalk to make that happen? > > I'm looking into it already because of this bug. This was done in 4.4.1-3, hence closing. Ian.

Hello. I played with UEFI PXE booting the other day, and as usual, used qemu/kvm virtual machine for initial testing/debugging, because it is way easier and faster for this task than using a real hardware. However, it looks like either qemu or {pxe,sys}linux 6.03 is buggy, -- the two does not play well together. When booting, the system successfully loads syslinux.efi, at least the tftp server

>getting messages that it can't activate ldap plugin I dont see that here. And ldap works fine. Can you post the message you get at the dbfix Or any other errors you see, these are most helpfull. I fixed my db also and it all still works fine. But if you can show how you see your errors i'll check that agains my env. But untill now is dont have any problems, but maybe is missed

On Mon, Dec 22, 2014 at 05:05:36AM -0800, Patrick Masotta wrote: > ok I'm not building from git; I just downloaded/extracted "syslinux-6.03.tar.gz" into a directory and build it from there. > Now I've erased the "> /dev/null 2>&1 " from check-gnu-efi.sh and I'm getting. > > fatal: Not a git repository (or any of the parent directories): .git

>> DHCP seems to be working properly - returning the correct boot file >>> for the architecture of the PXE client, but when I try to boot >>> syslinux.efi, it gets the file then keeps requesting ldinux.e64 over >>> and over again. The file is there and available. A wireshark trace >>> shows it keeps requesting the file, followed by the server

close 409392 thanks Disregard - I should be using the stable hypervisor. -- nate carlson / ncarlson@ibsys.com / 651-365-4124 sr. systems administrator - nbcsports.com @ ib

Package: blktap-dkms Version: 2.0.93-0.2 Severity: serious Justification: fails to build from source (but built successfully in the past) The build fails on 3.14 kernel with the following error: /var/lib/dkms/blktap/2.0.93/build/ring.c: In function ?blktap_ring_make_tr_request?: /var/lib/dkms/blktap/2.0.93/build/ring.c:314:32: error: ?struct bio? has no member named ?bi_sector?

Thanks Johannes to clarify this point. It makes more sense to me now. So I understand that the idea is to make it simpler without apt-pinning for less adventurous people (I mean normal people :)): just add jessie-cran3 repo and you're good to go. Am I also correct that jessie-cran3 is essentially a backport of Debian SID, with some (short?) delay? In other words, modulo a couple of days,

Dear Johannes, Thanks a lot for this work! I have to admit that I'm now a little bit puzzled, though. I'm running Debian Jessie (current testing) with great satisfaction. When it comes to R, I simply have the SID repository (official Debian) enabled, with some pining to get only R-related stuff. Now, I'm not sure to understand the benefit of using the CRAN repository for Jessie?I

>> DHCP seems to be working properly - returning the correct boot file >> for the architecture of the PXE client, but when I try to boot >> syslinux.efi, it gets the file then keeps requesting ldinux.e64 over >> and over again. The file is there and available. A wireshark trace >> shows it keeps requesting the file, followed by the server responding to the

Dear Mathieu, dear list, if you have successfully set up apt pinning for R packages, then you have the most up-to date Debian packages for R at your fingertips. I set up the repository for Debian jessie so people do not have to use apt pinning in order to get Debian 3.1.2 on jessie. Plus, when jessie is released, the repository is already there, and after the release of jessie it is likely

Yes, but beware that I only do backports of the packages listed in the Debian README on CRAN. Kind regards, Johannes Am Donnerstag, 26. Februar 2015, 10:06:08 schrieb Mathieu Basille: > Thanks Johannes to clarify this point. It makes more sense to me now. So I > understand that the idea is to make it simpler without apt-pinning for less > adventurous people (I mean normal people :)):

On Thu, Dec 13, 2018 at 10:57 AM Ady Ady via Syslinux <syslinux at zytor.com> wrote: > > @Carl, > > I'll repeat what I said in my prior email: you don't have to keep > looking, we already achieved what you want (considering that you are > willing to "disregard" the screen problems and similar issues, at least > for now, according to your own emails).