Locked in grub rescue after upgrade

[godfuture]

Hi, I have tried release 4.7 and it seems to work fine. After upgrade scripts were through, I have rebooted my machine. During startup, I was redirected to grub rescue with error message: symbol ´grub_calloc´ not found. Entering rescue mode...

As it worked before upgrade, is there anything that might have been gone wrong? I saw grub config was updated during upgrade.

[dleidert]

I had the same issue when I recently upgraded a server of mine. This is not OMV related. I fixed it by booting a Debian installer cd and entering rescue mode to reinstall grub. I don't know why this happens or how to prevent it.

[dleidert]

Can you provide the upgrade script?

[dleidert]

Are you using any kind of encryption?

[dleidert]

https://bugs.debian.org/966575, especially #95

If you can reproduce the situation I'd really be interested in the following information:

sudo debconf-show grub-pc | grep -w grub-pc/install_devices
ls -lA /dev/disk/*    (or whatever the above command returns)

and check if the device is the one you actually want grub be installed at (in my case there was indeed an outdated device listed). You can also try if using the advice given before restarting the system helps:

dpkg-reconfigure grub-pc

If that helps I have to figure out a way how to check for this.

[godfuture]

I had the same issue when I recently upgraded a server of mine. This is not OMV related. I fixed it by booting a Debian installer cd and entering rescue mode to reinstall grub. I don't know why this happens or how to prevent it.

I could also solve it by installing grub. But simply running update-grub did not help. There were more steps needed. Dont remember now what exactly. I will get back to this.

Can you provide the upgrade script?

Sorry, what upgrade script do you mean? I was referring to the installation process triggered by your upgrade scripts.

Are you using any kind of encryption?

Yes, dm-crypt/luks for a lot of my drives. Boot and root is on RAID1 and no encryption layer on top (-> raid/lvm2). But most of my data drives are encrypted (-> raid/luks/lvm2) which get automatically opened at startup by usb device holding a key.

If you can reproduce the situation I'd really be interested in the following information:

Yes, I can do that. I stored a virtualbox machine state which brings me directly back to the system after upgrade. No problemo! :)

[dleidert]

Can you provide the upgrade script?

Sorry, what upgrade script do you mean? I was referring to the installation process triggered by your upgrade scripts.

I meant the upgrade log.

However I wrote this before I found #966575. When I checked the advice given in the bug report I found that indeed the information in my debconf database was outdated and had led to the issue for me because it got GRUB installed into the wrong MBR. So I'm actually more interested in the debconf output.

[godfuture]

So I'm actually more interested in the debconf output.

root@server:~# sudo debconf-show grub-pc | grep -w grub-pc/install_devices * grub-pc/install_devices: /dev/disk/by-id/ata-SanDisk_SD8SB8U128G1122_171740425191

root@server:~# ls -lA /dev/disk/*

/dev/disk/by-id:
insgesamt 0
lrwxrwxrwx 1 root root  9 Jan 24 20:00 ata-VBOX_CD-ROM_VB1-01f003f6 -> ../../sr0
lrwxrwxrwx 1 root root  9 Jan 24 20:00 ata-VBOX_HARDDISK_VB47b04888-a08a4f08 -> ../../sdb
lrwxrwxrwx 1 root root  9 Jan 24 20:00 ata-VBOX_HARDDISK_VBe6b99997-0b64cffa -> ../../sda
lrwxrwxrwx 1 root root 10 Jan 24 20:00 ata-VBOX_HARDDISK_VBe6b99997-0b64cffa-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 Jan 24 20:00 dm-name-sandisk_raid1-docker -> ../../dm-1
lrwxrwxrwx 1 root root 10 Jan 24 20:00 dm-name-sandisk_raid1-logs -> ../../dm-3
lrwxrwxrwx 1 root root 10 Jan 24 20:00 dm-name-sandisk_raid1-omv -> ../../dm-2
lrwxrwxrwx 1 root root 10 Jan 24 20:00 dm-name-sandisk_raid1-root -> ../../dm-0
lrwxrwxrwx 1 root root 10 Jan 24 20:00 dm-uuid-LVM-t6pqzmi5EuOK9I82QJ8Sx0XwuEvS5hXIBvJNCrxk9LUmqpxEak7qF2MkVgu9cHX3 -> ../../dm-0
lrwxrwxrwx 1 root root 10 Jan 24 20:00 dm-uuid-LVM-t6pqzmi5EuOK9I82QJ8Sx0XwuEvS5hXIKKNRuE9553hxhqeQ99JUfi30H29HsqV1 -> ../../dm-2
lrwxrwxrwx 1 root root 10 Jan 24 20:00 dm-uuid-LVM-t6pqzmi5EuOK9I82QJ8Sx0XwuEvS5hXILpDSeYhp2fEB1mZcGALwMPeiUqPdK6W5 -> ../../dm-1
lrwxrwxrwx 1 root root 10 Jan 24 20:00 dm-uuid-LVM-t6pqzmi5EuOK9I82QJ8Sx0XwuEvS5hXIs2h1XtNZzI2dHsq1DNs36m3AFd4fqAgo -> ../../dm-3
lrwxrwxrwx 1 root root  9 Jan 24 20:00 lvm-pv-uuid-bJS3b8-y53L-YT4T-h8yj-dVZt-u8M5-24edXy -> ../../md4
lrwxrwxrwx 1 root root  9 Jan 24 20:00 md-name-server:4 -> ../../md4
lrwxrwxrwx 1 root root  9 Jan 24 20:00 md-uuid-0ecb12cf:029c9bcf:b4777155:b7368556 -> ../../md4

I have mirror my original system disk to a virtual disk for upgrade tests. Might this be the issue?

[dleidert]

I have mirror my original system disk to a virtual disk for upgrade tests. Might this be the issue?

Yes, that is the problem leading to #966575. The scripts are non-interactive (actually: must be non-interactive). So you could reconfigure grub-pc and then run the upgrade scripts.

[godfuture]

Yes, that is the problem leading to #966575. The scripts are non-interactive (actually: must be non-interactive). So you could reconfigure grub-pc and then run the upgrade scripts.

I executed grub-install /dev/sdx and it seems that this fixed my issues. As you said this issue is related to devices that have gone missing before omv upgrade.

[dleidert]

I've added a check for this recently. See the linked pull request #23. Feel free to check it out.