Bugzilla – Bug 1156
Trying to boot a BE that had been left mounted before the reboot will fail.
Last modified: 2009-01-14 02:16:36 UTC
You need to log in before you can comment on or make changes to this bug.
If I activate a mounted BE then reboot without unmounting the BE, the whole OS will fail to reboot afterwards. Because the BE is still mounted on original mount point not legacy mounted. Here is the steps: 1. beadm create NEWBE 2. beadm mount NEWBE /a 3. beadm activate NEWBE 4. beadm list BE Active Active on Mountpoint Space Name reboot Used ---- ------ ----------- ------------ ----- NEWBE no yes /mnt 2.80G opensolaris yes no - 5.08G 5. reboot After the rebooting, the OS fail to boot up. Because the NEWBE is still mounting on the /mnt. # beadm list BE Active Active on Mountpoint Space Name reboot Used ---- ------ ----------- ------------ ----- NEWBE yes yes /mnt 2.80G opensolaris no no - 5.08G
The problem is that the root dataset being booted is failing to get remounted rw (by filesystem/usr) since its mountpoint isn't set to legacy. A typical boot failure seen when this bug is encountered is: Use is subject to license terms. Hostname: opensolaris Apr 28 16:05:08 svc.startd[7]: svc:/system/sysevent:default: Method "/lib/svc/method/svc-syseventd start" failed with exit status 95. Apr 28 16:05:08 svc.startd[7]: system/sysevent:default failed fatally: transition to maintenance (see 'svcs -xv' for details) '/usr/sbin/pmconfig: cannot open/create "/etc/.cpr_config", Bad file number Requesting System Maintenance Mode (See /lib/svc/share/README for more information.) Console login service(s) cannot run Root password for system maintenance (control-d to bypass): To workaround this, one must reboot the system and choose the previously booted entry from the GRUB menu. When the system comes up, reset the mountpoint of the activated boot environment by running "beadm unmount <boot_environment>. Then reboot the system.
This reboot failure no longer happens post-build 88. With ZFS Boot, the root dataset no longer needs to have its mountpoint property set to 'legacy' for it to boot. However, when it is booted, zfs will show its mountpoint to be whatever it was previously left mounted at, and this can't be changed while its mounted at root. The correct course of action to repair this scenario is still to boot back to some previous BE, and resetting the mountpoint of the activated boot environment by running "beadm unmount <boot_environment>. Then reboot the system. Since the boot failure no longer occurs though, the defect is getting closed.
*** Bug 4735 has been marked as a duplicate of this bug. ***
I know I shouldn't be making a comment in closed bug. I just think the evaluation of this bug just didn't take the root cause into consideration, why /usr/sbin/pmconfig: insists of opening/creating "/etc/.cpr_config". This same problem will also happen if the root fs is readonly hecen diskless client will suffer from the same feat.