[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: xen-users@xxxxxxxxxxxxx
  • From: Alexandre Kouznetsov <alk@xxxxxxxxxx>
  • Date: Tue, 26 Jun 2012 16:47:13 -0500
  • Delivery-date: Tue, 26 Jun 2012 21:48:32 +0000
  • List-id: Xen user discussion <xen-users.lists.xen.org>

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.