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

[Shane Johnson <sdj@xxxxxxxxxxxxxxxxxxxxxx>]

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

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