Fresh install Squeeze with Backports - (Has happened on plain Squeeze and Wheezy installs too) Everything worked fine with this install till I installed xen-qemu-dm-4.0. After I installed this, I started getting ''elf_init : not and ELF binary'' while it was trying to load Domain 0. And now I have removed xen-qemu-dm-4.0 and am still getting the errors. I can boot into non Xen kernel fine. I actually have experienced this with two MB''s. The first was a Asus KGPE-D16. I bought the Tyan cause I thought the Asus was just being flaky. System Config MB: Tyan S8230GM4NR-LE CPU: 2x AMD Opteron 6174 Mem: 64 GB DDR3 registered memory (tested multiple times with memtest) My rough install procedure was as follows: from Debian Live CD (Sqeeze) Followed https://help.ubuntu.com/10.04/installation-guide/i386/linux-upgrade.html except for the following. install media is Raid 5 on 6 disks with LVM structure on top of it. Network Interfaces (4) are bonded and bridge is using bond. Initial kernel is linux-image-3.2.0-0.bpo.2-amd64 rebooted to host system. installed Xfce4 desktop , vim, etc... recompiled kernel using config from /boot as starting point and only changed what http://wiki.xen.org/wiki/Secondary_GPU_Passthrough said to. I used these instructions http://www.debian.org/releases/stable/i386/ch08s06.html.en to do the recompile and install the kernel. installed xen-linux-system-3.2.0-0.bpo.2-amd64 then create HVM config script. Got errors then installed xen-qemu-dm-4.0 and that is when I started getting the Elf binary errors when I try and boot with the Xen system. If I boot to the non-xen version of the same kernel, It boots fine. Please let me know if you need more information or if I need to do more testing. Thank you Shane D. Johnson IT Administrator Rasmussen Equipment
Ok resolved this myself - apparently no update-grub is done after the xen-qemu-dm-4.0 install to add the placeholder into the /boot/grub/grub.cfg file. Once update-grub was run - problem disappeared. Sorry for the chatter. Shane On Fri, Jun 22, 2012 at 11:45 AM, Shane Johnson <sdj@rasmussenequipment.com> wrote:> Fresh install Squeeze with Backports - (Has happened on plain Squeeze > and Wheezy installs too) Everything worked fine with this install till > I installed xen-qemu-dm-4.0. After I installed this, I started > getting ''elf_init : not and ELF binary'' while it was trying to load > Domain 0. And now I have removed xen-qemu-dm-4.0 and am still getting > the errors. I can boot into non Xen kernel fine. I actually have > experienced this with two MB''s. The first was a Asus KGPE-D16. I > bought the Tyan cause I thought the Asus was just being flaky. > > > System Config > MB: Tyan S8230GM4NR-LE > CPU: 2x AMD Opteron 6174 > Mem: 64 GB DDR3 registered memory (tested multiple times with memtest) > > My rough install procedure was as follows: > from Debian Live CD (Sqeeze) > Followed https://help.ubuntu.com/10.04/installation-guide/i386/linux-upgrade.html > except for the following. > install media is Raid 5 on 6 disks with LVM structure on top of it. > Network Interfaces (4) are bonded and bridge is using bond. > Initial kernel is linux-image-3.2.0-0.bpo.2-amd64 > rebooted to host system. > installed Xfce4 desktop , vim, etc... > recompiled kernel using config from /boot as starting point and only > changed what http://wiki.xen.org/wiki/Secondary_GPU_Passthrough said > to. I used these instructions > http://www.debian.org/releases/stable/i386/ch08s06.html.en to do the > recompile and install the kernel. > installed xen-linux-system-3.2.0-0.bpo.2-amd64 then create HVM config > script. Got errors then installed xen-qemu-dm-4.0 and that is when I > started getting the Elf binary errors when I try and boot with the Xen > system. If I boot to the non-xen version of the same kernel, It boots > fine. > > Please let me know if you need more information or if I need to do more testing. > > Thank you > > Shane D. Johnson > IT Administrator > Rasmussen Equipment-- Shane D. Johnson IT Administrator Rasmussen Equipment
Hello. El 22/06/12 14:28, Shane Johnson escribió:> Ok resolved this myself - apparently no update-grub is done after the > xen-qemu-dm-4.0 installThat''s a reason to check if your installation is ok, normally Debian is very careful to trigger everything need to run on a post-install. Otherwise, a reason for a bug report. Great thing it was resolved. -- Alexandre Kouznetsov
Well, I was still getting the error and finally just let go for the weekend and came back to it today. Been doing different testing all day then the very dim light bulb finally lit and I remembered that I did find a solution on one of my previous installs. (Yes it''s a very dim light bulb - sorry) So I am adding my solution here for prosperity. It would seem that for some reason with this setup it can''t use vmlinuz files that compressed with bzip2. Therefore I followed these instructions : http://old-list-archives.xen.org/archives/html/xen-users/2010-09/msg00586.html and now it is working fine. If anyone wants to know what my testing turned up - I will be more than happy to share but the link above provides a working solution. Hope this helps. Shane On Fri, Jun 22, 2012 at 2:16 PM, Alexandre Kouznetsov <alk@ondore.com> wrote:> Hello. > > El 22/06/12 14:28, Shane Johnson escribió: > >> Ok resolved this myself - apparently no update-grub is done after the >> xen-qemu-dm-4.0 install > > That''s a reason to check if your installation is ok, normally Debian is very > careful to trigger everything need to run on a post-install. > > Otherwise, a reason for a bug report. > > Great thing it was resolved. > > -- > Alexandre Kouznetsov > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users-- Shane D. Johnson IT Administrator Rasmussen Equipment
Hello. El 25/06/12 17:54, Shane Johnson escribió:> It would seem that for some reason with this setup it can''t use > vmlinuz files that compressed with bzip2. Therefore I followed these > instructions : > http://old-list-archives.xen.org/archives/html/xen-users/2010-09/msg00586.html > and now it is working fine.What''s so special in your setup? Home-complied kernel or hypervisor image? Debian stock Xen boots bzip2-compressed Dom0 kernels just fine, : # file /boot/vmlinuz-2.6.32-5-xen-amd64 /boot/vmlinuz-2.6.32-5-xen-amd64: Linux kernel x86 boot executable bzImage, version 2.6.32-5-xen-amd64 (unknown@Deb, RO-rootFS, swap_dev 0x2, Normal VGA Your experience is valuable, it''s just unclear, what configuration does it apply to. -- Alexandre Kouznetsov
On Mon, Jun 25, 2012 at 5:03 PM, Alexandre Kouznetsov <alk@ondore.com> wrote:> Hello. > > El 25/06/12 17:54, Shane Johnson escribió: > >> It would seem that for some reason with this setup it can''t use >> vmlinuz files that compressed with bzip2. Therefore I followed these >> instructions : >> >> http://old-list-archives.xen.org/archives/html/xen-users/2010-09/msg00586.html >> and now it is working fine. > > What''s so special in your setup? > Home-complied kernel or hypervisor image? > > Debian stock Xen boots bzip2-compressed Dom0 kernels just fine, : > # file /boot/vmlinuz-2.6.32-5-xen-amd64 > /boot/vmlinuz-2.6.32-5-xen-amd64: Linux kernel x86 boot executable bzImage, > version 2.6.32-5-xen-amd64 (unknown@Deb, RO-rootFS, swap_dev 0x2, Normal VGA > > Your experience is valuable, it''s just unclear, what configuration does it > apply to. > > > -- > Alexandre Kouznetsov > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-usersBesides what I posted in the OP I don''t see anything different. Here is what I observed: Kernels installed on server: 1 - linux-image-3.2.0-0.bpo-amd64 2 - linux-image-3.2.18 (recompiled) 3 - linux-image-3.2.0-0.bpo-amd64 with Xen 4 - linux-image-3.2.18 with Xen 5 - (all of the above with failsafe) All kernels would boot and run fine before xen-qemu-dm-4.0 installed. After - with Xen kernels would only boot after reinstalling package and full power down of server No With Xen kernel would run with xen-pciback.hide line in /boot/grub/grub.cfg All non with Xen options would boot fine. After 3.2.18 was extracted and made a raw image - no problems with booting and xen-pciback.hide. Same behavior on two MB. (See OP) so I don''t think it is a hardware problem, but I have two other Xen servers running and they don''t have this problem but they are not actual server components. I thought it might be a problem with the ECC so I turned it off with no change. At that point I remembered the instructions I posted earlier today so I didn''t do any other tests, just got it working. I am more than willing to do more tests, I just need to know what you would like me to run. Thanks -- Shane D. Johnson IT Administrator Rasmussen Equipment
On Tue, 2012-06-26 at 00:03 +0100, Alexandre Kouznetsov wrote:> Hello. > > El 25/06/12 17:54, Shane Johnson escribió: > > It would seem that for some reason with this setup it can''t use > > vmlinuz files that compressed with bzip2. Therefore I followed these > > instructions : > > http://old-list-archives.xen.org/archives/html/xen-users/2010-09/msg00586.html > > and now it is working fine. > What''s so special in your setup? > Home-complied kernel or hypervisor image? > > Debian stock Xen boots bzip2-compressed Dom0 kernels just fine, : > # file /boot/vmlinuz-2.6.32-5-xen-amd64 > /boot/vmlinuz-2.6.32-5-xen-amd64: Linux kernel x86 boot executable > bzImage, version 2.6.32-5-xen-amd64 (unknown@Deb, RO-rootFS, swap_dev > 0x2, Normal VGAbzImage != bzip2. A bzImage is a *big*zImage, big meaning that the kernel image can be larger than some ancient real-mode limit (~1M, I think). A bzImage can use one of a number of compression algorithms, historically gzip but bzip2, lzma and xz are also supported by the kernel these days -- you''d have to look in the relevant config to see which used by a particular image. I believe Debian 2.6.32 kernels used gzip. Ian.
On Tue, 2012-06-26 at 00:41 +0100, Shane Johnson wrote:> On Mon, Jun 25, 2012 at 5:03 PM, Alexandre Kouznetsov <alk@ondore.com> wrote: > > Hello. > > > > El 25/06/12 17:54, Shane Johnson escribió: > > > >> It would seem that for some reason with this setup it can't use > >> vmlinuz files that compressed with bzip2. Therefore I followed these > >> instructions : > >> > >> http://old-list-archives.xen.org/archives/html/xen-users/2010-09/msg00586.html > >> and now it is working fine. > > > > What's so special in your setup? > > Home-complied kernel or hypervisor image? > > > > Debian stock Xen boots bzip2-compressed Dom0 kernels just fine, : > > # file /boot/vmlinuz-2.6.32-5-xen-amd64 > > /boot/vmlinuz-2.6.32-5-xen-amd64: Linux kernel x86 boot executable bzImage, > > version 2.6.32-5-xen-amd64 (unknown@Deb, RO-rootFS, swap_dev 0x2, Normal VGA > > > > Your experience is valuable, it's just unclear, what configuration does it > > apply to. > > > > > > -- > > Alexandre Kouznetsov > > > > _______________________________________________ > > Xen-users mailing list > > Xen-users@lists.xen.org > > http://lists.xen.org/xen-users > > Besides what I posted in the OP I don't see anything different. Here > is what I observed: > Kernels installed on server: > 1 - linux-image-3.2.0-0.bpo-amd64 > 2 - linux-image-3.2.18 (recompiled) > 3 - linux-image-3.2.0-0.bpo-amd64 with Xen > 4 - linux-image-3.2.18 with Xen > 5 - (all of the above with failsafe) > > All kernels would boot and run fine before xen-qemu-dm-4.0 installed. > After - with Xen kernels would only boot after reinstalling package > and full power down of serverI'm hard pressed to think of a reason that installing xen-qemu-dm-4.0 should effect the boot of the host. This package contains a binary application which is only run when starting an HVM guest and has nothing at all to do with host kernels etc. I've checked the package content and the maintainer scripts and can't see anything untoward. Perhaps it is just a coincidence and something else which is happening around the same time as installing this package during host setup is the culprit? It might be interesting to take copies of /boot/grub/*.cfg and record md5sums of everything under /boot before installing the package so as to see what has actually changed.> No With Xen kernel would run with xen-pciback.hide line in /boot/grub/grub.cfgThis sounds like an unrelated issue? You mentioned Squeeze backports -- you shouldn't need xen-qemu-dm-4.0 with anything newer than the 4.0 version of Xen in Squeeze itself. Although I still can't think of a way this would cause host boot failures. Hrm, perhaps xen-qemu-dm-4.0 is causing an older (4.0) Xen to get pulled in and replace the newer backports one? Can you provide a transcript of the full "apt-get install xen-qemu-dm-4.0"? A full boot log of a failing system would also be useful. Can you also confirm which precise hypervisor packages you are installing (versions and where they come from). You only mentioned backports but not the specifics.> All non with Xen options would boot fine. > > After 3.2.18 was extracted and made a raw image - no problems with > booting and xen-pciback.hide. > Same behavior on two MB. (See OP) so I don't think it is a hardware > problem, but I have two other Xen servers running and they don't have > this problem but they are not actual server components. I thought it > might be a problem with the ECC so I turned it off with no change. At > that point I remembered the instructions I posted earlier today so I > didn't do any other tests, just got it working. I am more than > willing to do more tests, I just need to know what you would like me > to run. > > Thanks >_______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users
El 26/06/12 01:09, Ian Campbell escribió:> On Tue, 2012-06-26 at 00:03 +0100, Alexandre Kouznetsov wrote: >> Hello. >> >> El 25/06/12 17:54, Shane Johnson escribió: >>> It would seem that for some reason with this setup it can''t use >>> vmlinuz files that compressed with bzip2. Therefore I followed these >>> instructions : >>> http://old-list-archives.xen.org/archives/html/xen-users/2010-09/msg00586.html >>> and now it is working fine. >> What''s so special in your setup? >> Home-complied kernel or hypervisor image? >> >> Debian stock Xen boots bzip2-compressed Dom0 kernels just fine, : >> # file /boot/vmlinuz-2.6.32-5-xen-amd64 >> /boot/vmlinuz-2.6.32-5-xen-amd64: Linux kernel x86 boot executable >> bzImage, version 2.6.32-5-xen-amd64 (unknown@Deb, RO-rootFS, swap_dev >> 0x2, Normal VGA > > bzImage != bzip2. A bzImage is a *big*zImage, big meaning that the > kernel image can be larger than some ancient real-mode limit (~1M, I > think). A bzImage can use one of a number of compression algorithms, > historically gzip but bzip2, lzma and xz are also supported by the > kernel these days -- you''d have to look in the relevant config to see > which used by a particular image.That was new, ty.> I believe Debian 2.6.32 kernels used gzip.True, CONFIG_KERNEL_GZIP=y # grep ZIP /boot/config-2.6.32-5-xen-amd64 CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_BZIP2 is not set CONFIG_RD_GZIP=y CONFIG_RD_BZIP2=y # CONFIG_SCSI_IZIP_EPP16 is not set # CONFIG_SCSI_IZIP_SLOW_CTR is not set CONFIG_DECOMPRESS_GZIP=y CONFIG_DECOMPRESS_BZIP2=y -- Alexandre Kouznetsov Systems Officer Ondore, S.A. de C.V. Tel. +52(55) 5559-0090 E-mail alk@ondore.com
On Tue, Jun 26, 2012 at 7:43 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:> On Tue, 2012-06-26 at 00:41 +0100, Shane Johnson wrote: >> On Mon, Jun 25, 2012 at 5:03 PM, Alexandre Kouznetsov <alk@ondore.com> wrote: >> > Hello. >> > >> > El 25/06/12 17:54, Shane Johnson escribió: >> > >> >> It would seem that for some reason with this setup it can''t use >> >> vmlinuz files that compressed with bzip2. Therefore I followed these >> >> instructions : >> >> >> >> http://old-list-archives.xen.org/archives/html/xen-users/2010-09/msg00586.html >> >> and now it is working fine. >> > >> > What''s so special in your setup? >> > Home-complied kernel or hypervisor image? >> > >> > Debian stock Xen boots bzip2-compressed Dom0 kernels just fine, : >> > # file /boot/vmlinuz-2.6.32-5-xen-amd64 >> > /boot/vmlinuz-2.6.32-5-xen-amd64: Linux kernel x86 boot executable bzImage, >> > version 2.6.32-5-xen-amd64 (unknown@Deb, RO-rootFS, swap_dev 0x2, Normal VGA >> > >> > Your experience is valuable, it''s just unclear, what configuration does it >> > apply to. >> > >> > >> > -- >> > Alexandre Kouznetsov >> > >> > _______________________________________________ >> > Xen-users mailing list >> > Xen-users@lists.xen.org >> > http://lists.xen.org/xen-users >> >> Besides what I posted in the OP I don''t see anything different. Here >> is what I observed: >> Kernels installed on server: >> 1 - linux-image-3.2.0-0.bpo-amd64 >> 2 - linux-image-3.2.18 (recompiled) >> 3 - linux-image-3.2.0-0.bpo-amd64 with Xen >> 4 - linux-image-3.2.18 with Xen >> 5 - (all of the above with failsafe) >> >> All kernels would boot and run fine before xen-qemu-dm-4.0 installed. >> After - with Xen kernels would only boot after reinstalling package >> and full power down of server > > I''m hard pressed to think of a reason that installing xen-qemu-dm-4.0 > should effect the boot of the host. This package contains a binary > application which is only run when starting an HVM guest and has nothing > at all to do with host kernels etc. > > I''ve checked the package content and the maintainer scripts and can''t > see anything untoward. > > Perhaps it is just a coincidence and something else which is happening > around the same time as installing this package during host setup is the > culprit? > > It might be interesting to take copies of /boot/grub/*.cfg and record > md5sums of everything under /boot before installing the package so as to > see what has actually changed. > >> No With Xen kernel would run with xen-pciback.hide line in /boot/grub/grub.cfg > > This sounds like an unrelated issue? > > You mentioned Squeeze backports -- you shouldn''t need xen-qemu-dm-4.0 > with anything newer than the 4.0 version of Xen in Squeeze itself. > Although I still can''t think of a way this would cause host boot > failures. > > Hrm, perhaps xen-qemu-dm-4.0 is causing an older (4.0) Xen to get pulled > in and replace the newer backports one? Can you provide a transcript of > the full "apt-get install xen-qemu-dm-4.0"? > > A full boot log of a failing system would also be useful. > > Can you also confirm which precise hypervisor packages you are > installing (versions and where they come from). You only mentioned > backports but not the specifics. > >> All non with Xen options would boot fine. >> >> After 3.2.18 was extracted and made a raw image - no problems with >> booting and xen-pciback.hide. >> Same behavior on two MB. (See OP) so I don''t think it is a hardware >> problem, but I have two other Xen servers running and they don''t have >> this problem but they are not actual server components. I thought it >> might be a problem with the ECC so I turned it off with no change. At >> that point I remembered the instructions I posted earlier today so I >> didn''t do any other tests, just got it working. I am more than >> willing to do more tests, I just need to know what you would like me >> to run. >> >> Thanks >> > >I ran md5sum on all files in /boot and /boot/grub/grub.cfg and nothing changed after xen-qemu-dm installed. ( I have those hashs if you want to see them. I checked the version of the hypervisor that gets installed and it''s only at 4.0.1-4 (I thought it would have been higher as well )(This is the same before and after xen-qemu is installed) the output from the installation of xen-qemu is attached ( If I am allowed, if not let me know how you want me to get the information to you.) I attempted to get a boot log for you, but the error occurs before bootlogd starts. Is there another way I can get the information for you? Thanks for all the help -- Shane D. Johnson IT Administrator Rasmussen Equipment _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users
Hello. Can you please show your grub.cfg, and the output of "ls -l /boot"? Specify what section of your grub.cfg is used when the "not an ELF binary" error occur. -- Alexandre Kouznetsov
On Tue, Jun 26, 2012 at 3:10 PM, Alexandre Kouznetsov <alk@ondore.com> wrote:> Hello. > > Can you please show your grub.cfg, and the output of "ls -l /boot"? > Specify what section of your grub.cfg is used when the "not an ELF binary" > error occur. > > -- > Alexandre Kouznetsov > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-usersls -l /boot -rw-r--r-- 1 root root 2007679 Jun 3 16:44 System.map-3.2.0-0.bpo.2-amd64 -rw-r--r-- 1 root root 2024845 Jun 3 17:15 System.map-3.2.0-0.bpo.2-rt-amd64 -rw-r--r-- 1 root root 2052633 Jun 21 15:02 System.map-3.2.18 -rw-r--r-- 1 root root 129015 Jun 3 16:44 config-3.2.0-0.bpo.2-amd64 -rw-r--r-- 1 root root 128580 Jun 3 17:15 config-3.2.0-0.bpo.2-rt-amd64 -rw-r--r-- 1 root root 128623 Jun 21 13:21 config-3.2.18 drwxr-xr-x 3 root root 4096 Jun 26 14:04 grub -rw-r--r-- 1 root root 11186911 Jun 25 16:13 initrd.img-3.2.0-0.bpo.2-amd64 -rw-r--r-- 1 root root 11305992 Jun 25 16:13 initrd.img-3.2.0-0.bpo.2-rt-amd64 -rw-r--r-- 1 root root 11133522 Jun 25 16:21 initrd.img-3.2.18 -rw-r--r-- 1 root root 2695559 Jun 25 16:18 initrd.img-vmlinuz-3.2.18-xen-amd64 -rw-r--r-- 1 root root 2846608 Jun 3 16:41 vmlinuz-3.2.0-0.bpo.2-amd64 -rw-r--r-- 1 root root 2895120 Jun 3 17:13 vmlinuz-3.2.0-0.bpo.2-rt-amd64 -rw-r--r-- 1 root root 2937200 Jun 26 14:08 vmlinuz-3.2.18 -rw-r--r-- 1 root root 11733424 Jun 26 14:07 vmlinuz-3.2.18-new -rw-r--r-- 1 root root 678554 Jun 9 2011 xen-4.0-amd64.gz Entry that causes panic - menuentry ''Debian GNU/Linux, with Linux 3.2.18 and XEN 4.0-amd64'' --class debian --class gnu-linux --class gnu --class os --class xen { insmod raid insmod raid5rec insmod mdraid insmod lvm insmod part_msdos insmod part_msdos insmod part_msdos insmod part_msdos insmod part_msdos insmod part_msdos insmod ext2 set root=''(vg-base)'' search --no-floppy --fs-uuid --set c7d94648-4c69-4512-a82c-37aa10c75893 echo ''Loading Linux 3.2.18 ...'' multiboot /boot/xen-4.0-amd64.gz placeholder module /boot/vmlinuz-3.2.18 placeholder root=/dev/mapper/vg-base ro quiet xen-pciback.hide=(05.00.0)(05:00.1) echo ''Loading initial ramdisk ...'' module /boot/initrd.img-3.2.18 Full boot.cfg attached. -- Shane D. Johnson IT Administrator Rasmussen Equipment _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users
Hello. El 26/06/12 16:26, Shane Johnson escribió:> On Tue, Jun 26, 2012 at 3:10 PM, Alexandre Kouznetsov <alk@ondore.com> wrote: >> Hello. >> >> Can you please show your grub.cfg, and the output of "ls -l /boot"? >> Specify what section of your grub.cfg is used when the "not an ELF binary" >> error occur. >> >> -- >> Alexandre Kouznetsov >> >> >> _______________________________________________ >> Xen-users mailing list >> Xen-users@lists.xen.org >> http://lists.xen.org/xen-users > > ls -l /boot > -rw-r--r-- 1 root root 2007679 Jun 3 16:44 System.map-3.2.0-0.bpo.2-amd64 > -rw-r--r-- 1 root root 2024845 Jun 3 17:15 System.map-3.2.0-0.bpo.2-rt-amd64 > -rw-r--r-- 1 root root 2052633 Jun 21 15:02 System.map-3.2.18 > -rw-r--r-- 1 root root 129015 Jun 3 16:44 config-3.2.0-0.bpo.2-amd64 > -rw-r--r-- 1 root root 128580 Jun 3 17:15 config-3.2.0-0.bpo.2-rt-amd64 > -rw-r--r-- 1 root root 128623 Jun 21 13:21 config-3.2.18 > drwxr-xr-x 3 root root 4096 Jun 26 14:04 grub > -rw-r--r-- 1 root root 11186911 Jun 25 16:13 initrd.img-3.2.0-0.bpo.2-amd64 > -rw-r--r-- 1 root root 11305992 Jun 25 16:13 initrd.img-3.2.0-0.bpo.2-rt-amd64 > -rw-r--r-- 1 root root 11133522 Jun 25 16:21 initrd.img-3.2.18 > -rw-r--r-- 1 root root 2695559 Jun 25 16:18 initrd.img-vmlinuz-3.2.18-xen-amd64 > -rw-r--r-- 1 root root 2846608 Jun 3 16:41 vmlinuz-3.2.0-0.bpo.2-amd64 > -rw-r--r-- 1 root root 2895120 Jun 3 17:13 vmlinuz-3.2.0-0.bpo.2-rt-amd64 > -rw-r--r-- 1 root root 2937200 Jun 26 14:08 vmlinuz-3.2.18 > -rw-r--r-- 1 root root 11733424 Jun 26 14:07 vmlinuz-3.2.18-new > -rw-r--r-- 1 root root 678554 Jun 9 2011 xen-4.0-amd64.gz > > Entry that causes panic - > menuentry ''Debian GNU/Linux, with Linux 3.2.18 and XEN 4.0-amd64'' > --class debian --class gnu-linux --class gnu --class os --class xen { > insmod raid > insmod raid5rec > insmod mdraid > insmod lvm > insmod part_msdos > insmod part_msdos > insmod part_msdos > insmod part_msdos > insmod part_msdos > insmod part_msdos > insmod ext2 > set root=''(vg-base)'' > search --no-floppy --fs-uuid --set c7d94648-4c69-4512-a82c-37aa10c75893 > echo ''Loading Linux 3.2.18 ...'' > multiboot /boot/xen-4.0-amd64.gz placeholder > module /boot/vmlinuz-3.2.18 placeholder root=/dev/mapper/vg-base ro > quiet xen-pciback.hide=(05.00.0)(05:00.1) > echo ''Loading initial ramdisk ...'' > module /boot/initrd.img-3.2.18 > > Full boot.cfg attached.I believe, vmlinuz-3.2.18 did not came with any Debian package (even sid/unstable includes up to 3.2.0). Maybe you compiled it yourself? In any case, the initial error is clearly 3.2.18''s fault. If you have no particular reason to use a custom kernel, I recommend you to stick to the repository. The installation of xen-qemu-dm-4.0 was supposed not to cause any troubles, but my hypotheses is that it somehow triggered update-grub re-creation (some unconfigured packages was present, maybe? there are several ways) and broke your previously working configuration. You said, you got errors while installing xen-qemu-dm-4.0. They are probably still in /vat/log/dpkg.log or /var/log/apt or /var/log/aptitude. If what exactly happened is still relevant, i would look for the answer there. If you have not touched your grub.cfg, it''s last modification date will tell you where to look in the logs. If you just need this to work, please consider removing all weired/unused kernel images, so update-grub can have less to mess with. Beware, some of those kernels might be still needed by your DomUs. -- Alexandre Kouznetsov
On Tue, Jun 26, 2012 at 3:47 PM, Alexandre Kouznetsov <alk@ondore.com> wrote:> Hello. > > El 26/06/12 16:26, Shane Johnson escribió: > >> On Tue, Jun 26, 2012 at 3:10 PM, Alexandre Kouznetsov <alk@ondore.com> >> wrote: >>> >>> Hello. >>> >>> Can you please show your grub.cfg, and the output of "ls -l /boot"? >>> Specify what section of your grub.cfg is used when the "not an ELF >>> binary" >>> error occur. >>> >>> -- >>> Alexandre Kouznetsov >>> >>> >>> _______________________________________________ >>> Xen-users mailing list >>> Xen-users@lists.xen.org >>> http://lists.xen.org/xen-users >> >> >> ls -l /boot >> -rw-r--r-- 1 root root 2007679 Jun 3 16:44 >> System.map-3.2.0-0.bpo.2-amd64 >> -rw-r--r-- 1 root root 2024845 Jun 3 17:15 >> System.map-3.2.0-0.bpo.2-rt-amd64 >> -rw-r--r-- 1 root root 2052633 Jun 21 15:02 System.map-3.2.18 >> -rw-r--r-- 1 root root 129015 Jun 3 16:44 config-3.2.0-0.bpo.2-amd64 >> -rw-r--r-- 1 root root 128580 Jun 3 17:15 config-3.2.0-0.bpo.2-rt-amd64 >> -rw-r--r-- 1 root root 128623 Jun 21 13:21 config-3.2.18 >> drwxr-xr-x 3 root root 4096 Jun 26 14:04 grub >> -rw-r--r-- 1 root root 11186911 Jun 25 16:13 >> initrd.img-3.2.0-0.bpo.2-amd64 >> -rw-r--r-- 1 root root 11305992 Jun 25 16:13 >> initrd.img-3.2.0-0.bpo.2-rt-amd64 >> -rw-r--r-- 1 root root 11133522 Jun 25 16:21 initrd.img-3.2.18 >> -rw-r--r-- 1 root root 2695559 Jun 25 16:18 >> initrd.img-vmlinuz-3.2.18-xen-amd64 >> -rw-r--r-- 1 root root 2846608 Jun 3 16:41 vmlinuz-3.2.0-0.bpo.2-amd64 >> -rw-r--r-- 1 root root 2895120 Jun 3 17:13 >> vmlinuz-3.2.0-0.bpo.2-rt-amd64 >> -rw-r--r-- 1 root root 2937200 Jun 26 14:08 vmlinuz-3.2.18 >> -rw-r--r-- 1 root root 11733424 Jun 26 14:07 vmlinuz-3.2.18-new >> -rw-r--r-- 1 root root 678554 Jun 9 2011 xen-4.0-amd64.gz >> >> Entry that causes panic - >> menuentry ''Debian GNU/Linux, with Linux 3.2.18 and XEN 4.0-amd64'' >> --class debian --class gnu-linux --class gnu --class os --class xen { >> insmod raid >> insmod raid5rec >> insmod mdraid >> insmod lvm >> insmod part_msdos >> insmod part_msdos >> insmod part_msdos >> insmod part_msdos >> insmod part_msdos >> insmod part_msdos >> insmod ext2 >> set root=''(vg-base)'' >> search --no-floppy --fs-uuid --set >> c7d94648-4c69-4512-a82c-37aa10c75893 >> echo ''Loading Linux 3.2.18 ...'' >> multiboot /boot/xen-4.0-amd64.gz placeholder >> module /boot/vmlinuz-3.2.18 placeholder root=/dev/mapper/vg-base >> ro >> quiet xen-pciback.hide=(05.00.0)(05:00.1) >> echo ''Loading initial ramdisk ...'' >> module /boot/initrd.img-3.2.18 >> >> Full boot.cfg attached. > > > I believe, vmlinuz-3.2.18 did not came with any Debian package (even > sid/unstable includes up to 3.2.0). Maybe you compiled it yourself? In any > case, the initial error is clearly 3.2.18''s fault. If you have no particular > reason to use a custom kernel, I recommend you to stick to the repository. > > The installation of xen-qemu-dm-4.0 was supposed not to cause any troubles, > but my hypotheses is that it somehow triggered update-grub re-creation (some > unconfigured packages was present, maybe? there are several ways) and broke > your previously working configuration. > > You said, you got errors while installing xen-qemu-dm-4.0. They are probably > still in /vat/log/dpkg.log or /var/log/apt or /var/log/aptitude. If what > exactly happened is still relevant, i would look for the answer there. If > you have not touched your grub.cfg, it''s last modification date will tell > you where to look in the logs. > > If you just need this to work, please consider removing all weired/unused > kernel images, so update-grub can have less to mess with. Beware, some of > those kernels might be still needed by your DomUs. > > > > -- > Alexandre Kouznetsov > > > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-usersAlexandre, Yes I compiled 3.2.18 - following Debian instructions with the debian sources. The only reason I compiled the kernel is that pciback is a module in the default kernel and loads xen-pciback.hide too late for hiding the video card from Dom0. Believe me, If I could get away with not compiling the kernel that would be my preference. As it stands, I do need to pass that video card to the VM on this server. This server is only going to be running one kernel and one VM (I choose this for disaster recovery) so the other kernels where just there so I could get a working system to compile the kernel I needed. I have to leave most of them so the dependencies for xen are satisfied in aptitude. The errors where not from the installation of xen-qemu-dm they happened on subsequent boots. (Same kernel panic ) And because this has to be a HVM machine, I have to use xen-qemu-dm until Debian moves to the newer version where it''s not required and this makes it so that no matter what kernel I use - I will be running into the problem of the kernel panic error message. I guess my from here my options are to use the uncompressed vmlinuz-3.2.18 file or possibly compile Xen from source. Where the uncompressed works - I will probably go with it. I was doing the testing today to try and help figure out why it was happening. (Still don''t understand why it''s only on this hardware I have the issue.) Than you. -- Shane D. Johnson IT Administrator Rasmussen Equipment
Hi.> Yes I compiled 3.2.18 - following Debian instructions with the debian > sources. The only reason I compiled the kernel is that pciback is a > module in the default kernel and loads xen-pciback.hide too late for > hiding the video card from Dom0. Believe me, If I could get away > with not compiling the kernel that would be my preference.That is what I referred to as "particular reason". So, you have one, the pain is justified (:> The errors where not from the installation of xen-qemu-dm they > happened on subsequent boots. (Same kernel panic )Oh. I understood that during install something went wrong and you saw errors. As it''s not so, forget about package manager logs.> And because this > has to be a HVM machine, I have to use xen-qemu-dm until Debian moves > to the newer version where it''s not required and this makes it so that > no matter what kernel I use - I will be running into the problem of > the kernel panic error message.Well, the error start to appear aster xen-qemu-dm was installed, so I suspect the installation of the package triggered some condition. I''m really curious about how it happened, but it seems that it has little to do with the solution. In a neighbor branch of this thread Ian suggested that bz2 compression was the difference between working an broken. I would consider to re-build the custom kernel, making sure it''s compressed in a closest to the default way. I think re-building the kernel is a better documented option, than re-compiling Xen. That way you can get a reproducible stable setup.> (Still > don''t understand why it''s only on this hardware I have the issue.)Missed that until now, sorry. Are you super-double-sure that you are using the same boot files on different hardware, with different results? md5sum can help to make file comparison. Generally, bz2 compression is little bit more stressful for the CPU than gzip, but it sounds too exotic to make the difference. -- Alexandre Kouznetsov
On Tue, 2012-06-26 at 21:57 +0100, Shane Johnson wrote:> I ran md5sum on all files in /boot and /boot/grub/grub.cfg and nothing > changed after xen-qemu-dm installed. ( I have those hashs if you want > to see them.That''s ok, if they are the same then they are the same.> I checked the version of the hypervisor that gets installed and it''s > only at 4.0.1-4 (I thought it would have been higher as well )(This is > the same before and after xen-qemu is installed)Did you reboot into this hypervisor before installing xen-qemu?> the output from the installation of xen-qemu is attached ( If I am > allowed, if not let me know how you want me to get the information to > you.)Nothing untoward seems to happen here.> I attempted to get a boot log for you, but the error occurs before > bootlogd starts. Is there another way I can get the information for > you?Either serial console http://wiki.xen.org/wiki/Xen_Serial_Console or if that isn''t an option then a digital photo of the screen (you might want to add noreboot to the hypervisor command line to give yourself time to take the photo).> > Thanks for all the help >
On Tue, 2012-06-26 at 22:26 +0100, Shane Johnson wrote:> On Tue, Jun 26, 2012 at 3:10 PM, Alexandre Kouznetsov <alk@ondore.com> wrote: > > Hello. > > > > Can you please show your grub.cfg, and the output of "ls -l /boot"? > > Specify what section of your grub.cfg is used when the "not an ELF binary" > > error occur. > > > > -- > > Alexandre Kouznetsov > > > > > > _______________________________________________ > > Xen-users mailing list > > Xen-users@lists.xen.org > > http://lists.xen.org/xen-users > > ls -l /boot > -rw-r--r-- 1 root root 2007679 Jun 3 16:44 System.map-3.2.0-0.bpo.2-amd64 > -rw-r--r-- 1 root root 2024845 Jun 3 17:15 System.map-3.2.0-0.bpo.2-rt-amd64 > -rw-r--r-- 1 root root 2052633 Jun 21 15:02 System.map-3.2.18 > -rw-r--r-- 1 root root 129015 Jun 3 16:44 config-3.2.0-0.bpo.2-amd64 > -rw-r--r-- 1 root root 128580 Jun 3 17:15 config-3.2.0-0.bpo.2-rt-amd64 > -rw-r--r-- 1 root root 128623 Jun 21 13:21 config-3.2.18 > drwxr-xr-x 3 root root 4096 Jun 26 14:04 grub > -rw-r--r-- 1 root root 11186911 Jun 25 16:13 initrd.img-3.2.0-0.bpo.2-amd64 > -rw-r--r-- 1 root root 11305992 Jun 25 16:13 initrd.img-3.2.0-0.bpo.2-rt-amd64 > -rw-r--r-- 1 root root 11133522 Jun 25 16:21 initrd.img-3.2.18 > -rw-r--r-- 1 root root 2695559 Jun 25 16:18 initrd.img-vmlinuz-3.2.18-xen-amd64 > -rw-r--r-- 1 root root 2846608 Jun 3 16:41 vmlinuz-3.2.0-0.bpo.2-amd64 > -rw-r--r-- 1 root root 2895120 Jun 3 17:13 vmlinuz-3.2.0-0.bpo.2-rt-amd64 > -rw-r--r-- 1 root root 2937200 Jun 26 14:08 vmlinuz-3.2.18 > -rw-r--r-- 1 root root 11733424 Jun 26 14:07 vmlinuz-3.2.18-new > -rw-r--r-- 1 root root 678554 Jun 9 2011 xen-4.0-amd64.gz > > Entry that causes panic -Is it just this one or are others faulty too? Do the bpo kernels work? What about the 2.6.32-xen kernel from Squeeze proper (as an experiment). I think you can ignore any concerns about pciback hiding here -- your failure is well before that would make any difference. [...]> module /boot/vmlinuz-3.2.18 placeholder root=/dev/mapper/vg-base ro > quiet xen-pciback.hide=(05.00.0)(05:00.1)What does file /boot/vmlinuz-3.2.18 say? What about this using the attached bzexplode: ./bzexplode /boot/vmlinuz-3.2.18 | file - and then, depending on the type of compression that reports: ./bzexplode /boot/vmlinuz-3.2.18 | zcat | file - (exchange zcat for the appropriate FOOcat, although if it isn''t gzip then that would be a good thing to fix first).> echo ''Loading initial ramdisk ...'' > module /boot/initrd.img-3.2.18 > > Full boot.cfg attached. >_______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users
On Tue, 2012-06-26 at 23:14 +0100, Shane Johnson wrote:> On Tue, Jun 26, 2012 at 3:47 PM, Alexandre Kouznetsov <alk@ondore.com> wrote: > > Hello. > > > > El 26/06/12 16:26, Shane Johnson escribió: > > > >> On Tue, Jun 26, 2012 at 3:10 PM, Alexandre Kouznetsov <alk@ondore.com> > >> wrote: > >>> > >>> Hello. > >>> > >>> Can you please show your grub.cfg, and the output of "ls -l /boot"? > >>> Specify what section of your grub.cfg is used when the "not an ELF > >>> binary" > >>> error occur. > >>> > >>> -- > >>> Alexandre Kouznetsov > >>> > >>> > >>> _______________________________________________ > >>> Xen-users mailing list > >>> Xen-users@lists.xen.org > >>> http://lists.xen.org/xen-users > >> > >> > >> ls -l /boot > >> -rw-r--r-- 1 root root 2007679 Jun 3 16:44 > >> System.map-3.2.0-0.bpo.2-amd64 > >> -rw-r--r-- 1 root root 2024845 Jun 3 17:15 > >> System.map-3.2.0-0.bpo.2-rt-amd64 > >> -rw-r--r-- 1 root root 2052633 Jun 21 15:02 System.map-3.2.18 > >> -rw-r--r-- 1 root root 129015 Jun 3 16:44 config-3.2.0-0.bpo.2-amd64 > >> -rw-r--r-- 1 root root 128580 Jun 3 17:15 config-3.2.0-0.bpo.2-rt-amd64 > >> -rw-r--r-- 1 root root 128623 Jun 21 13:21 config-3.2.18 > >> drwxr-xr-x 3 root root 4096 Jun 26 14:04 grub > >> -rw-r--r-- 1 root root 11186911 Jun 25 16:13 > >> initrd.img-3.2.0-0.bpo.2-amd64 > >> -rw-r--r-- 1 root root 11305992 Jun 25 16:13 > >> initrd.img-3.2.0-0.bpo.2-rt-amd64 > >> -rw-r--r-- 1 root root 11133522 Jun 25 16:21 initrd.img-3.2.18 > >> -rw-r--r-- 1 root root 2695559 Jun 25 16:18 > >> initrd.img-vmlinuz-3.2.18-xen-amd64 > >> -rw-r--r-- 1 root root 2846608 Jun 3 16:41 vmlinuz-3.2.0-0.bpo.2-amd64 > >> -rw-r--r-- 1 root root 2895120 Jun 3 17:13 > >> vmlinuz-3.2.0-0.bpo.2-rt-amd64 > >> -rw-r--r-- 1 root root 2937200 Jun 26 14:08 vmlinuz-3.2.18 > >> -rw-r--r-- 1 root root 11733424 Jun 26 14:07 vmlinuz-3.2.18-new > >> -rw-r--r-- 1 root root 678554 Jun 9 2011 xen-4.0-amd64.gz > >> > >> Entry that causes panic - > >> menuentry ''Debian GNU/Linux, with Linux 3.2.18 and XEN 4.0-amd64'' > >> --class debian --class gnu-linux --class gnu --class os --class xen { > >> insmod raid > >> insmod raid5rec > >> insmod mdraid > >> insmod lvm > >> insmod part_msdos > >> insmod part_msdos > >> insmod part_msdos > >> insmod part_msdos > >> insmod part_msdos > >> insmod part_msdos > >> insmod ext2 > >> set root=''(vg-base)'' > >> search --no-floppy --fs-uuid --set > >> c7d94648-4c69-4512-a82c-37aa10c75893 > >> echo ''Loading Linux 3.2.18 ...'' > >> multiboot /boot/xen-4.0-amd64.gz placeholder > >> module /boot/vmlinuz-3.2.18 placeholder root=/dev/mapper/vg-base > >> ro > >> quiet xen-pciback.hide=(05.00.0)(05:00.1) > >> echo ''Loading initial ramdisk ...'' > >> module /boot/initrd.img-3.2.18 > >> > >> Full boot.cfg attached. > > > > > > I believe, vmlinuz-3.2.18 did not came with any Debian package (even > > sid/unstable includes up to 3.2.0). Maybe you compiled it yourself? In any > > case, the initial error is clearly 3.2.18''s fault. If you have no particular > > reason to use a custom kernel, I recommend you to stick to the repository. > > > > The installation of xen-qemu-dm-4.0 was supposed not to cause any troubles, > > but my hypotheses is that it somehow triggered update-grub re-creation (some > > unconfigured packages was present, maybe? there are several ways) and broke > > your previously working configuration. > > > > You said, you got errors while installing xen-qemu-dm-4.0. They are probably > > still in /vat/log/dpkg.log or /var/log/apt or /var/log/aptitude. If what > > exactly happened is still relevant, i would look for the answer there. If > > you have not touched your grub.cfg, it''s last modification date will tell > > you where to look in the logs. > > > > If you just need this to work, please consider removing all weired/unused > > kernel images, so update-grub can have less to mess with. Beware, some of > > those kernels might be still needed by your DomUs. > > > > > > > > -- > > Alexandre Kouznetsov > > > > > > > > > > _______________________________________________ > > Xen-users mailing list > > Xen-users@lists.xen.org > > http://lists.xen.org/xen-users > > Alexandre, > Yes I compiled 3.2.18 - following Debian instructions with the debian > sources. The only reason I compiled the kernel is that pciback is a > module in the default kernel and loads xen-pciback.hide too late for > hiding the video card from Dom0. Believe me, If I could get away > with not compiling the kernel that would be my preference. As it > stands, I do need to pass that video card to the VM on this server. > This server is only going to be running one kernel and one VM (I > choose this for disaster recovery) so the other kernels where just > there so I could get a working system to compile the kernel I needed. > I have to leave most of them so the dependencies for xen are satisfied > in aptitude.Can you get a system up and running using stock Debian packages, without pci passthrough, just as a proof of concept? That will make it easier to switch out the kernel and other changes individually.> The errors where not from the installation of xen-qemu-dm they > happened on subsequent boots. (Same kernel panic ) And because this > has to be a HVM machine, I have to use xen-qemu-dm until Debian moves > to the newer version where it''s not requiredNote that a qemu-dm will always be required for an HVM guest, it''s just that newer Debian''s will include it in the Xen package direct and/or depend on the mainline qemu package to provide this function.> and this makes it so that > no matter what kernel I use - I will be running into the problem of > the kernel panic error message. > I guess my from here my options are to use the uncompressed > vmlinuz-3.2.18 file or possibly compile Xen from source. Where the > uncompressed works - I will probably go with it. I was doing the > testing today to try and help figure out why it was happening. (Still > don''t understand why it''s only on this hardware I have the issue.)Have you run a memory tester? memtest86+ or similar? Ian.
I am going to consolidate my answers here to try and make this easier to follow. from the HVM help please - wrong GRUB entry? thread - from Ian: Can you get a system up and running using stock Debian packages, without pci passthrough, just as a proof of concept? That will make it easier to switch out the kernel and other changes individually. yes I can - will just take me a little while today. I will get you the results once it''s completed. Have you run a memory tester? memtest86+ or similar? Yes - have actually run it multiple time just cause this seemed so much like a hardware problem - Everytime, no errors I will run it again tonight overnight to make sure. If you don''t feel this is needed please let me know. From this thread : Did you reboot into this hypervisor before installing xen-qemu? Yes - I was in my desired hypervisor when I got the error that reminded me I needed the xen-qemu-dm package. Either serial console http://wiki.xen.org/wiki/Xen_Serial_Console or if that isn''t an option then a digital photo of the screen (you might want to add noreboot to the hypervisor command line to give yourself time to take the photo). I will do the noreboot and get you as many screenshots as I can. As a additional note - When I was getting some of the information last night, it seems that it only does the kernel panic when the xen-pciback.hide is on the command line in grub.cfg. I will do more testing to confirm this and let you know. This could be the difference with this machine and the others I am running since this one is the only one I am doing the vga passthrough. If I get a chance I have my desktop running a VM on it that I can try and do passthrough on and see if it replicates. Only problem is I can''t do any testing till after 5 Mountain time (US). On Wed, Jun 27, 2012 at 1:33 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:> On Tue, 2012-06-26 at 21:57 +0100, Shane Johnson wrote: >> I ran md5sum on all files in /boot and /boot/grub/grub.cfg and nothing >> changed after xen-qemu-dm installed. ( I have those hashs if you want >> to see them. > > That''s ok, if they are the same then they are the same. > >> I checked the version of the hypervisor that gets installed and it''s >> only at 4.0.1-4 (I thought it would have been higher as well )(This is >> the same before and after xen-qemu is installed) > > Did you reboot into this hypervisor before installing xen-qemu? > >> the output from the installation of xen-qemu is attached ( If I am >> allowed, if not let me know how you want me to get the information to >> you.) > > Nothing untoward seems to happen here. > >> I attempted to get a boot log for you, but the error occurs before >> bootlogd starts. Is there another way I can get the information for >> you? > > Either serial console http://wiki.xen.org/wiki/Xen_Serial_Console or if > that isn''t an option then a digital photo of the screen (you might want > to add noreboot to the hypervisor command line to give yourself time to > take the photo). > >> >> Thanks for all the help >> > >-- Shane D. Johnson IT Administrator Rasmussen Equipment
On Wed, 2012-06-27 at 15:09 +0100, Shane Johnson wrote:> I am going to consolidate my answers here to try and make this easier > to follow. > > from the HVM help please - wrong GRUB entry? thread - > from Ian: > Can you get a system up and running using stock Debian packages, without > pci passthrough, just as a proof of concept? That will make it easier to > switch out the kernel and other changes individually. > > yes I can - will just take me a little while today. I will get you > the results once it''s completed.Thanks.> Have you run a memory tester? memtest86+ or similar? > > Yes - have actually run it multiple time just cause this seemed so > much like a hardware problem - Everytime, no errors > I will run it again tonight overnight to make sure. If you don''t feel > this is needed please let me know.If you''ve already run it then no need to go again.> From this thread : > Did you reboot into this hypervisor before installing xen-qemu? > > Yes - I was in my desired hypervisor when I got the error that > reminded me I needed the xen-qemu-dm package.And you are sure it was the exact same hypervisor + kernel which you booted (or tried to boot) both before and after installing xen-qemu-dm? [...]> As a additional note - When I was getting some of the information > last night, it seems that it only does the kernel panic when the > xen-pciback.hide is on the command line in grub.cfg. I will do more > testing to confirm this and let you know.There is absolutely no way that only changing the kernel kernel command line in this way can cause you to go from a booting system to the "not an ELF binary" message you are seeing -- this is simply way before anything takes any notice of the kernel''s command line. Something else must be changing at the same time. The only thing I can think of is that there is some arbitrary limit on the command line length in the boot loader or something, but from the picture you sent your command line is not unusually long. You could put some garbage (e.g. "placeholderplaceholder") instead of pci-back.hide etc to rule this out. Ian.