[OmniOS-discuss] OmniOS r151022 is now out!
Dominik Hassler
hasslerd at gmx.li
Tue May 16 15:50:04 UTC 2017
Addendum:
Just upgraded another system and there booting from both rpool devices
works.
This system has a different mainboard, so I wonder if it is BIOS related
and a BIOS upgrade on system 1 could help?
Another difference:
System 1 has been set-up in summer 2013, so it went r06 -> r08 -> ... -> r22
System 2 has been set-up in end of 2014, so it went r12 -> R14 -> ... -> r22
Not sure if that might have an impact, when OmniOS was set-up first
(e.g. how partitions are created by installer)
On 05/16/2017 03:53 PM, Dominik Hassler wrote:
> Ok, I did an installboot -mFf on both disks again (-v is not available
> for installboot)
>
> $ sudo installboot -mFf /boot/pmbr /boot/gptzfsboot
> /dev/rdsk/c9t5000CCA04103E0B5d0s0
> bootblock written for /dev/rdsk/c9t5000CCA04103E0B5d0s0, 223 sectors
> starting at 1024 (abs 33154)
> stage1 written to slice 1 sector 0 (abs 16065)
> stage1 written to master boot sector
>
> $ sudo installboot -mFf /boot/pmbr /boot/gptzfsboot
> /dev/rdsk/c10t5000CCA04103E095d0s0
> bootblock written for /dev/rdsk/c10t5000CCA04103E095d0s0, 223 sectors
> starting at 1024 (abs 33154)
> stage1 written to slice 1 sector 0 (abs 16065)
> stage1 written to master boot sector
>
> checked the version:
>
> $ installboot -i /boot/gptzfsboot
> Extended version string: 1.1-2017.4.23.2
> MD5 hash: 766b5059c45796f049bb38b80e1a1c4d
>
> and compared it to the version of both disks:
>
> $ sudo installboot -i /dev/rdsk/c9t5000CCA04103E0B5d0s0
> Extended version string: 1.1-2017.4.23.2
> MD5 hash: 766b5059c45796f049bb38b80e1a1c4d
>
> $ sudo installboot -i /dev/rdsk/c10t5000CCA04103E095d0s0
> Extended version string: 1.1-2017.4.23.2
> MD5 hash: 766b5059c45796f049bb38b80e1a1c4d
>
>
> everything matches, but still the system boots only from one disk and
> not the other. Since it is not the latest version you mentioned I'll
> just wait until it is updated I guess. I can at least boot from one disk
> so I am not too worried about it at the moment. Still I would prefer to
> be able to boot from both.
>
> On 05/16/2017 03:18 PM, Toomas Soome wrote:
>>
>>> On 16. mai 2017, at 15:58, Dominik Hassler <hasslerd at gmx.li> wrote:
>>>
>>> Toomas,
>>>
>>> using a (forced) installboot on both rpool mirror devices did the
>>> trick. Loader is now being used.
>>>
>>> However there is another problem. I can boot w/o problems from the
>>> first device. But booting fails from the second device w/ the
>>> following message:
>>>
>>> Can't find /boot/zfsloader
>>>
>>> illumos/x86 boot
>>> Default: disk-1:/boot/zfsloader
>>
>> Somehow the MBR on second disk is not properly updated and I think it
>> has wrong size recorded for stage2.
>>
>> The initial installboot was implemented based on installgrub source
>> and we record the LBA with gptzfsboot start sector, and size (in
>> sectors) into MBR.
>>
>> Now the copy of the MBR (the /boot/pmbr file) is also installed into
>> partition start sector 0), and when the beadm activate is run, the
>> boot blocks are updates, but with same logic, that with MBR+VTOC case,
>> the MBR itself is not updated (to keep multi boot setups safe), and
>> only partition sector 0 and stage 2 are updated. The oversight is that
>> the MBR is loading stage2 directly, and if the gptzfsboot size was
>> changed, the result is that not the entire gptzfsboot is read into the
>> memory and resulting with just the output as you can see.
>>
>> later we did create the fix for installboot - the fixed installboot
>> will only record the location and size (1 sector) of the partition
>> boot recors (partition relative sector 0), and after that the MBR code
>> will read in the partition block, the partition block will read the
>> stage2, and so the MBR+VTOC case is not an issue any more.
>>
>> to fix this, run installboot -mFfv against that second disk to ensure
>> the MBR block is properly updated - note the -v again, so you can
>> confirm the MBR and partition block and stage2 are all updated.
>>
>> With installgrub we actually have the same issue, except, the grub
>> stage2 size virtually did not change and thats why the problem was
>> never revealed.
>>
>> note, if your installboot command does allow to read the version from
>> /boot/gptzfsboot like that:
>>
>> $ installboot -i /boot/gptzfsboot
>> Extended version string: 1.1-2017.5.6.2
>> MD5 hash: 2907581de9ca6bd4d2c12695a32cb749
>>
>> then it has the bug fixed, and after installing MBR with such binary,
>> the MBR is always reading the sector 0 from partition start, and the
>> future updates are ok.
>>
>> also note that MBR is always updated with GPT, and hence there the
>> issue does not appear (which why it took some time to notice it - my
>> own test systems were all using GPT:)
>>
>> rgds,
>> toomas
>>
>>> boot:
>>>
>>>
>>> Debug info below:
>>>
>>> $ sudo installboot -i /dev/rdsk/c10t5000CCA04103E095d0s0
>>> Extended version string: 1.1-2017.4.23.2
>>> MD5 hash: 766b5059c45796f049bb38b80e1a1c4d
>>>
>>> same on both devices
>>>
>>>
>>> $ sudo format -> select disk -> fdisk
>>> Total disk size is 36481 cylinders
>>> Cylinder size is 16065 (512 byte) blocks
>>>
>>> Cylinders
>>> Partition Status Type Start End Length %
>>> ========= ====== ============ ===== === ====== ===
>>> 1 Active Solaris2 1 36480 36480 100
>>>
>>> same on both devices
>>>
>>>
>>> $ sudo prtvtoc /dev/rdsk/c10t5000CCA04103E095d0s2
>>> * /dev/rdsk/c10t5000CCA04103E095d0s2 partition map
>>> *
>>> * Dimensions:
>>> * 512 bytes/sector
>>> * 63 sectors/track
>>> * 255 tracks/cylinder
>>> * 16065 sectors/cylinder
>>> * 36480 cylinders
>>> * 36478 accessible cylinders
>>> *
>>> * Flags:
>>> * 1: unmountable
>>> * 10: read-only
>>> *
>>> * Unallocated space:
>>> * First Sector Last
>>> * Sector Count Sector
>>> * 0 16065 16064
>>> *
>>> * First Sector Last
>>> * Partition Tag Flags Sector Count Sector Mount Directory
>>> 0 2 00 16065 586003005 586019069
>>> 2 5 01 0 586051200 586051199
>>> 8 1 01 0 16065 16064
>>>
>>>
>>> same on both devices
>>>
>>>
>>> boot: status
>>> Default: disk-1:/boot/zfsloader
>>> boot: statusdisk devices:
>>> disk0: BIOS drive C ...
>>> disk0a: root
>>> disk0i: boot
>>> disk1: BIOS drive D ...
>>> disk1s1: Solaris 2
>>> disk1s1a: root
>>> disk1s1i: boot
>>> ....
>>> zfs devices:
>>> pool: rpool
>>> bootfs: rpool/ROOT/omnios-r151022
>>> config:
>>>
>>> NAME STATE
>>> rpool DEGRADED
>>> mirror DEGRADED
>>> c9t5000CCA04103E0B5d0s2 ONLINE
>>> c10t5000CCA04103E095d0s0 OFFLINE
>>>
>>> illumos/x86 boot
>>> Default: disk-1:/boot/zfsloader
>>> boot:
>>>
>>>
>>> Any hints on how to get the system boot from both rpool devices are
>>> highly appreciated.
>>>
>>>
>>> Kind regards,
>>> Dominik
>>>
>>> On 05/15/2017 08:40 PM, Toomas Soome wrote:
>>>>
>>>>> On 15. mai 2017, at 21:06, Dan McDonald <danmcd at omniti.com> wrote:
>>>>>
>>>>>
>>>>>> On May 15, 2017, at 12:49 PM, Dominik Hassler <hasslerd at gmx.li>
>>>>>> wrote:
>>>>>>
>>>>>> Hey,
>>>>>>
>>>>>> after the upgrade, the boot loader is still GRUB.
>>>>>>
>>>>>> I did the upgrade according to the upgrade notes. Rebooted once,
>>>>>> did a:
>>>>>>
>>>>>> $ sudo beadm activate omnios-r151022
>>>>>> WARNING: menu.lst file /rpool/boot/menu.lst does not exist,
>>>>>> generating a new menu.lst file
>>>>>> Activated successfully
>>>>>>
>>>>>> checked for a /etc/default/be file. there is none. Still the boot
>>>>>> loader is GRUB instead of loader.
>>>>>
>>>>> Are you on a mirrored root pool? It's possible the libbe code that
>>>>> installs loader doesn't do it to all disks in a mirrored pool...
>>>>>
>>>>> Worst-case scenario is to explicitly install it:
>>>>>
>>>>> foreach (drive)
>>>>> installboot -m /boot/pmbr /boot/gptzfsboot /dev/rdsk/<drive>
>>>>>
>>>>> Dan
>>>>>
>>>>
>>>> The problem you have is that beadm activate does not enforce MBR
>>>> update in case of MBR+VTOC partitioning; you need to either run
>>>> bootadm install-bootloader -Mfv or installboot -mv.
>>>>
>>>> Note that installboot and bootadm install-bootloader have slightly
>>>> different flags; -v is good to have there, so you will see if the
>>>> MBR was updated or not.
>>>>
>>>> The beadm activate and bootadm use the same mechanism to update the
>>>> bootblocks on all pool member disks, bootadm does have extra flag to
>>>> allow MBR update. installboot does only update specified disk.
>>>>
>>>> rgds,
>>>> toomas
>>>>
>>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
More information about the OmniOS-discuss
mailing list