grub2 update problems for 3.4 (GUI only), leading to not correctly installed packages

Re: grub2 update problems (GUI only), leading to not correctly installed packages

franca said:
I updated thorugh the CLI but stil had the Grub not completing the installation issue.
Click to expand...

Me too, thankfully though I managed to reboot perhaps thanks to dietmar's advice of "grub-install /dev/sda", my machine is a few thousand clicks away so hands on for me is not an option.
 
Re: grub2 update problems for 3.4 (GUI only), leading to not correctly installed pack

Hello,

Same problem for me...
I have the enterprise subscription, I made the update in an SSH session, everything went well but... on reboot, "grub rescue mode".
The solution was to boot the server with supergrub disk and to reinstall grub (grub-install /dev/sda), now it works.

I think too that it could be a good idea to have a notification or an alert before the update for this kind of problem...
 
Re: grub2 update problems for 3.4 (GUI only), leading to not correctly installed pack

did you make sure sda isnt in use by your usb drive?

I suggest you type "dmesg | grep sd" and take a look to what drives you have running before installing a grub onto your usb stick :)

In my case I had to grub-install /dev/sdb
 
Re: grub2 update problems for 3.4 (GUI only), leading to not correctly installed pack

Hi there!

Here is how I resolved this issue with failed GRUB update (Hetzner server, LVM installation):

1. First you need to boot your server from Live CD or other rescue image;
2. Second find out your "/boot" partition (mine was /dev/md0) and "/" root partition (mine was /dev/mapper/vg0-root);
3. Then mount like this:

Code: 
mount /dev/mapper/vg0-root /mnt
mount /dev/md0 /mnt/boot
mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys

4. Chroot into mounted

Code: 
chroot /mnt

5. Edit the following files:

in /etc/default/grub (add or edit):

Code: 
GRUB_DISABLE_LINUX_UUID=true
GRUB_PRELOAD_MODULES="raid dmraid"

in /etc/modules
and /etc/initramfs-tools/modules (add or edit):

Code: 
raid1

6. Run

Code: 
grub-install /dev/sda
grub-install /dev/sdb
update-grub
update-initramfs -u

7. Exit chroot "Ctrl+A+D"
8. Reboot

Hope this helps.

Regards,
DevBaku
 
Re: grub2 update problems for 3.4 (GUI only), leading to not correctly installed pack

I updated using the Web interface and I noticed 2 things that I don't know if they're related to the upgrade:

- iscsi targets were not showing. VMs that had iSCSI disks were unoperable. lvscan and vgscan reported errors. After fighting with hours with it and restoring the backups to new VMs with NFS, I brought those VMs back in service. /etc/init.d/open-iscsi restart seemed to help iSCSI
- To test if the host was working OK, I wanted to migrate VMs to the other hosts online, but I keep getting the following:

Mar 01 12:37:36 starting migration of VM 106 to node 'allen-pmx2' (172.16.14.151)
Mar 01 12:37:36 copying disk images
Mar 01 12:37:36 starting VM 106 on remote node 'allen-pmx2'
Mar 01 12:37:37 start failed: command '/usr/bin/kvm -id 106 -chardev 'socket,id=qmp,path=/var/run/qemu-server/106.qmp,server,nowait' -mon 'chardev=qmp,mode=control' -vnc unix:/var/run/qemu-server/106.vnc,x509,password -pidfile /var/run/qemu-server/106.pid -daemonize -name ntop -smp 'sockets=1,cores=2' -nodefaults -boot 'menu=on' -vga cirrus -cpu kvm64,+lahf_lm,+x2apic,+sep -k en-us -m 512 -device 'piix3-usb-uhci,id=uhci,bus=pci.0,addr=0x1.0x2' -device 'usb-tablet,id=tablet,bus=uhci.0,port=1' -device 'virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3' -drive 'if=none,id=drive-ide2,media=cdrom,aio=native' -device 'ide-cd,bus=ide.1,unit=0,drive=drive-ide2,id=ide2,bootindex=200' -drive 'file=/mnt/pve/N4F_NFS2/images/106/vm-106-disk-1.qcow2,if=none,id=drive-virtio0,format=qcow2,aio=native,cache=none' -device 'virtio-blk-pci,drive=drive-virtio0,id=virtio0,bus=pci.0,addr=0xa' -netdev 'type=tap,id=net0,ifname=tap106i0,script=/var/lib/qemu-server/pve-bridge,vhost=on' -device 'virtio-net-pci,mac=9A:12:BD:12:7B:C6,netdev=net0,bus=pci.0,addr=0x12,id=net0,bootindex=300' -machine 'type=pc-i440fx-2.1' -incoming tcp:localhost:60000 -S' failed: exit code 1
Mar 01 12:37:37 ERROR: online migrate failure - command '/usr/bin/ssh -o 'BatchMode=yes' root@172.16.14.151 qm start 106 --stateuri tcp --skiplock --migratedfrom proxmox1 --machine pc-i440fx-2.1' failed: exit code 255
Mar 01 12:37:37 aborting phase 2 - cleanup resources
Mar 01 12:37:37 migrate_cancel
Mar 01 12:37:37 ERROR: migration finished with problems (duration 00:00:01)
TASK ERROR: migration problems

We don't want to update the other host until we resolve these issues (and can't update the other host since we cannot move the critical VMs to it)

Any suggestions? Thanks
 
Re: grub2 update problems for 3.4 (GUI only), leading to not correctly installed pack

I upgraded via an ssh command prompt:
apt-get dist-upgrade

On one server, I was not prompted to do anything with Grub, but on two other servers it prompted me saying something like this:

"You've opted not to upgrade grub, do you want to proceed without installing grub2 somewhere"?

Like I said, this is not the exact thing it said, but similar. Anyway, I chose to proceed without installing a grub2 boot loader anywhere.

Is this the recommended action? Is there any official documentation addressing the best practice for this grub 2 issue? What issues will NOT installing grub2 cause during future package upgrades? I want to do this the right way, but how is that?
 
Re: grub2 update problems for 3.4 (GUI only), leading to not correctly installed pack

Lonnie said:
Is this the recommended action?
Click to expand...

You should really install the new grub boot loader, else you run into problems on reboot. Please run

# dpkg-reconfigure grub-pc

Note: Usually /deva/sda is the correct location for the boot loader.
 
Re: grub2 update problems for 3.4 (GUI only), leading to not correctly installed pack

dietmar said:
Note: Usually /deva/sda is the correct location for the boot loader.
Click to expand...

Is there a command I can type (without installing additional packages), in Proxmox, that can verify (with certainty) the device path to which grub is currently installed? I don't like:

1) holding my breath
2) select /dev/sda as Grub destination
3) Rebooting
4) Praying it reboots.

This did work on my least important production server, but I felt like I was playing Russian Roulette. I fear using this technique for all the production servers.

Update: I did a thorough backup of all my virtual machines, then proceeded selecting /dev/sda as the Grub destination for all the production servers. Each one did reboot fine, but I still desire a command that would verify Grub's current destination; I don't like proceeding based on probability instead of certainty.

I'll also mention that this command:
dpkg-reconfigure grub-pc

It does prompt you for two other questions before you actually select /dev/sda as the Grub destination (the first question was this). Please tell me if this is wrong, but, I just chose "OK" to what ever defaults were provided for those two preceding questions, then selected /dev/sda as the Grub destination. Each server did reboot fine, despite the fact that I had no clue what to enter into those two proceeding questions (leaving the first one blank, and accepting the default "Quiet" for the second one).

Most of the servers, in my case, were Dell Power Edge T620, and the /dev/sda selection also made mention of the dell h710 perc controller (which are using RAID 10). This fact provided a little bit of encouragement as I proceeded on each subsequent server.
 
Last edited:
Re: grub2 update problems for 3.4 (GUI only), leading to not correctly installed pack

I second the last comment about a command that can verify the device path to which grub is currently installed. My Proxmox installations on a site are on iSCSI boot disks and that's not where you want to find out that grub is not working
 
Re: grub2 update problems for 3.4 (GUI only), leading to not correctly installed pack

After fighting with the VMs that didn't want to be migrated, I found out that they were VMs that were created on the Proxmox host that had been upgraded and when the migration process started, the other host didn't understand the 'type=pc-i440fx-2.1', since it only supported earlier versions. I wonder if there's a way to create VMs in upgraded hosts so that they're compatible with other hosts in the cluster. This is something that might happen other times in the middle of a Proxmox upgrade in a cluster.
 
Re: grub2 update problems for 3.4 (GUI only), leading to not correctly installed pack

What should i do, i'm using enterprise repo

apt-get update
apt-get dist-upgrade
reboot

and now

Wellcome to GRUB!

error: file not found.
Entering rescue mode ....
grub rescue >


i'm using single disk, default install.


edit: problem solved

Code: 
-ubuntu 14.04 64bit live disc
-sudo -s
-mkdir /mnt/pve
-mount /dev/pve/root /mnt/pve
-mount /dev/pve/data /mnt/pve/var/lib/vz
-mount /dev/sda1 /mnt/pve/boot
-mount --bind -dev /mnt/pve/dev
-mount --bind /proc /mnt/pve/proc
-mount --bind /sys /mnt/pve/sys
-chroot /mnt/pve 
-grub-install /dev/sda 
-update-grub 
-update-initramfs -u
-crtl a+d
-reboot
 
Last edited:
Re: grub2 update problems for 3.4 (GUI only), leading to not correctly installed pack

tom said:
check your package status via 'pveversion -v' - if you have issues like (not correctly installed packages) do the following:
Click to expand...

Do you have a list of package versions I can reference against to determine if I am affected by this? I had already run the updates via GUI.
 
Re: grub2 update problems for 3.4 (GUI only), leading to not correctly installed pack

I had the same experience many times
Tired of continuing reissue.
The fundamental method is needed


1. os must be installed on a standard hard disk always first harddisk(/dev/sda). with cdrom media, not burned usb-stick
2. If you are using a regular hard disks as a RAID card, you must specify in the bios to a regular hard disk as a priority.
3. In all cases, should not be updated on the GUI.
4. The update should have been put off slowly.
5. Do not be recovered if a failure occurs should be clean installation. It is a new installation is much faster than the time to find the recovery.
 
Last edited:
Re: grub2 update problems for 3.4 (GUI only), leading to not correctly installed pack

Hi,


we upgraded our running Proxmox Hosts 3.3 to 3.4 via dist-upgrade.
On some (80%) of the hosts grub was not configured correct... after a reboot (DevCon 7 :()
We had the issue with GUI upgrade and also with ssh/console dist-upgrade, and also with "grub-install" after the ssh/console upgrade...


Our first intention was to boot the system from the 3.4 installation medium as described in the wiki.


https://pve.proxmox.com/wiki/Debugging_Installation
if you screwed up grub and can't boot from hd anymore, boot from the installer cdrom and at "boot:" prompt just type: pveboot (NOT preceded by "linux"). This will boot from cdrom and mount LVM root and data partitions
Click to expand...



Why is this helpful feature removed from the 3.4 installation medium?
In 3.2 it is still there (3.3 not tested...)


Greetings and great thx for the good job to the ProxMox-Team ;)
 
Re: grub2 update problems for 3.4 (GUI only), leading to not correctly installed pack

Is there a preferred way to make a "complete" grub backup before updating?
 
Re: grub2 update problems for 3.4 (GUI only), leading to not correctly installed pack

I want to share my experiences too, because they are subtly different from some of the others here. I had to upgrade Proxmox because one of my openvz containers was failing to boot, and updating from the pve-no-subscription repo did solve that problem - but it created a bigger problem in that Proxmox itself wouldn't boot. :-) I got the grub rescue> prompt. I fixed that using a Debian wheezy boot CD and running these commands (through trial and error): first, mounting a shell on /dev/mapper/pve-root and running:
grub-install /dev/cciss/c0d0
Click to expand...
In my case, installing to /dev/sda did not work. I don't know why. Then after rebooting this got me to a grub> prompt rather than a grub rescue> prompt which I regarded as progress. From there, I had to run these commands:
set root='(hd0,gpt2)'
linux vmlinuz-2.6.32-38-pve root /dev/mapper/pve-root
initrd /initrd.img-2.6.32-38-pve
boot
Click to expand...
Questions remain, why grub didn't pick up the kernel and initrd by itself. And what I need to do to ensure it does so (I suppose manually editing grub.cfg will do it, but that oughtn't to be necessary). Anyone have any ideas on that?
 
Last edited:
Re: grub2 update problems for 3.4 (GUI only), leading to not correctly installed pack

terminus said:
Questions remain, why grub didn't pick up the kernel and initrd by itself. And what I need to do to ensure it does so (I suppose manually editing grub.cfg will do it, but that oughtn't to be necessary). Anyone have any ideas on that?
Click to expand...

Turned out to be fairly easy. Reinstall grub-pc.
 
Re: grub2 update problems for 3.4 (GUI only), leading to not correctly installed pack

When upgrading 3.3 to 3.4 since most failed.
I recommand that do not upgrade 3.3 to 3.4.
I have being using the version 3.4 new-install.
Today upgrade grub2 has appeared again in proxmox-webgui.
I am afraid. But fortunately this time did nothing happens.


But another problem arose.
3rd LAN card is reaktek 8169 was a model.
A few months ago, Patch was the driver for this network card as a driver downloaded from the realtek site.
The reason is that the patch autoneg function error.
The role of the network card gateway.


Now was the upgrade over the proxmox-webgui.
After booting the PC, my third network card has disappeared.
It was not accessible from the outside, as did concerns. Brain was a panic.
It worried and tried to solve how to go up to the IDC.
Fortunately reappeared through the "modprobe r8169".


Upgrades are also afraid of work.
I will not for some time to upgrade.

--after upgrade and reboot-----------------------------------------------------
root@pve:~# ethtool eth2
Settings for eth2:
Cannot get device settings: No such device
Cannot get wake-on-lan settings: No such device
Cannot get message level: No such device
Cannot get link status: No such device
No data available

--reinstall realtek driver and works ...
...
ok.
 
Last edited:
You must log in or register to reply here.

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom