# [OmniOS-discuss] OmniOS r151022 is now out!

Dominik Hassler hasslerd at gmx.li
Tue May 16 15:50:04 UTC 2017

- Previous message: [OmniOS-discuss] OmniOS r151022 is now out!
- Next message: [OmniOS-discuss] OmniOS r151022 is now out!
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    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

- Previous message: [OmniOS-discuss] OmniOS r151022 is now out!
- Next message: [OmniOS-discuss] OmniOS r151022 is now out!
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

More information about the OmniOS-discuss mailing list