We're looking into this.

~Anil

Its possible this is another manifestation of a libfdisk bug, specifically CR 6913353, in the upstream OpenSolaris code base. We need to investigate further. Stay tuned.

• Garrett

Hi,

In order to find out whats wrong on my server I install Nexenta NCP3 RC1 in a VirtualBox on my Windows 7 Computer.

In file /boot/grub/menu.lst I find the following:

title Nexenta Core Platform "Hardy" [Auto-detect 32-bit/64-bit] kernel$ /platform/i86pc/kernel/$ISADIR/unix -B $ZFS-BOOTFS module$ /platform/i86pc/$ISADIR/boot_archive

So I try to set the GRUB commands by hand: grub> kernel$ /platform/i86pc/kernel/$ISADIR/unix -B $ZFS-BOOTFS
loading '/platform/i86pc/kernel/$ISADIR/unix -B $ZFS-BOOTFS' ...
cpu: 'GenuineIntel' family 6 model 14 step 5
[BIOS accepted mixed-mode target setting!]
checksum verification failed

Error 16: Inconsistent filesystem structure

What happens here ? How to repair this ?

Ernst

We're working on releasing a patch that I hope will fix this. Stay tuned.

• Garrett

Is there a known workaround for this problem or can you give an approx date for the patch?

Thanks for the heads-up, I upgraded from B3 to RC1 over the weekend, upgraded my storage pool from ZFS v22 to 25, but chose to leave the syspool alone. Glad to see this forum is very active.

Had some spare time today, so I tried to fix my system. What worked for me, was to reinstall GRUB from the RC1 cd.

All I had to do was to boot into the installer, change to the console (F2) and run:

zpool import (to get diskid of syspool)

cd /boot/grub

installgrub stage1 stage2 /dev/rdsk/diskid (repeat for each syspool disk)

reboot

Disclaimer: Try at your own risk ;-)

That solution worked for me, Thanks !

Great, work's perfect.

Thanks, Ernst

Thanks for this thread, helped me enormously. Same cause, same symptoms, same solution.

Thanks, Fred

+1 worked for me! Power finally went out and I had to reboot, this bit me today.

Maximilian S. wrote:

Had some spare time today, so I tried to fix my system. What worked for me, was to reinstall GRUB from the RC1 cd.

It worked for me! I've upgraded to RC2 and could not find the syspool/rootfs-nmu-002 filesystem. I've tried to boot from syspool/rootfs-nmu-001 and it was "inconsistent". I upgraded to zpool 25 too (before having this issue).

Thanks!

Maximilian S. wrote:

Had some spare time today, so I tried to fix my system. What worked for me, was to reinstall GRUB from the RC1 cd.

I just did an 'apt-clone dist-upgrade' from nexenta-core v3rc2 to v3rc3 and found myself with an unbootable system (stalled at grub prompt). Upgrading grub, following Maximilian's instructions got me working again. Thanks Maximilian!

Ben Poliakoff wrote:

Maximilian S. wrote:

Had some spare time today, so I tried to fix my system. What worked for me, was to reinstall GRUB from the RC1 cd.

I just did an 'apt-clone dist-upgrade' from nexenta-core v3rc2 to v3rc3 and found myself with an unbootable system (stalled at grub prompt). Upgrading grub, following Maximilian's instructions got me working again. Thanks Maximilian!

I had to do the same thing. :(

The Fix worked for me too. I ran into the same problem without updating anything ... just restarting Nexenta 3.0 inside VirtualBox crashed the boot loader.

Note, this issue bites Solaris, OpenSolaris (RIP), and I imagine Illumos OS users also.

The issue is that if you upgrade a zpool that is bootable you do not not want to forget to issue a command like (although on Solaris I use a '-m' flag):

installgrub stage1 stage2 /dev/rdsk/diskid

Maximilian S. (above) is almost 100% correct, but I don't think you need repeat for each syspool disk (unless I am confussed and a syspool in Nexenta mean bootable partition). The bottom line for every bootable partition that you do a zpool upgrade NEVER forget to re-install grub.

Note, there is no reason to re-install, if you have a bootable live-CD with a zpool revision equal to or greater than the zpool upgrade revision that bricked your system you can do the import and 'installgrub' to fix the issue (I have done this with both Solaris 10 and OpenSolaris a number of times)

In fact when doing any major patch set or cluster (sorry don't know hoe Nexenta calls updates/patches) I have found it to be a good idea to perform the above command as Sun (now Oracle) sometimes releases a bad patch or cluster script that doesn't do the 'installgrub ' but upgrades the boot zpool. The result is exactly what you saw a bricked system.

Note on Solaris 10 I typically use the '-m' option with a command as shown below for a mirrored ZFS boot disk just like -perhaps Nexenta also needs this but I am not sure:

installgrub -m /boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/c1t1d0s0

where the -m option means "Installs GRUB stage1 on the master boot sector interactively".

Cheers,

Jon Strabala

Worked for me too, today, even though the issue was discovered "about one year ago"...

Well, same here. Upgraded my syspool a few days ago, just did a reboot and had nothing but a grub> prompt waiting for me. I was also able to repair it using NexentaStor Community 3.1.1 using the steps above. I ran into another caveat in that I have my BIOS configured for AHCI and, unfortunately, was completely unable to boot to the disc. It failed with CDROM: discovery failed. I switch it off of AHCI and back to IDE mode and was able to boot to the CD. Just make sure and switch it back to AHCI after you have repaired grub, but before you boot back into your regular system, otherwise your disk ids will be way off and will have trouble finding anything other than c0d0s0.

How is it that something as simple as needing to reinstall grub after upgrading your syspool zfs version has not yet been resolved and be automatically occurring when this was reported well over a year ago? This is causing unnecessary hassle, and I can't fathom how this hasn't affected everybody under the sun who isn't aware of this "bug".