Re: [Xen-users] HVM help please - wrong GRUB entry?

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2012-06-26 at 23:14 +0100, Shane Johnson wrote:
> On Tue, Jun 26, 2012 at 3:47 PM, Alexandre Kouznetsov <alk@xxxxxxxxxx> wrote:
> > Hello.
> >
> > El 26/06/12 16:26, Shane Johnson escribió:
> >
> >> On Tue, Jun 26, 2012 at 3:10 PM, Alexandre Kouznetsov <alk@xxxxxxxxxx>
> >> 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@xxxxxxxxxxxxx
> >>> 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@xxxxxxxxxxxxx
> > 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 required

Note 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.



_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users