On 03/21/17 10:55 AM, Carsten Grzemba wrote:
On 27.02.17 08:42, Alexander Pyhalov <[email protected]> wrote:
Hello, guys.
Please take the notice that fixes on illumos loader did reveal additional
issues, resulted in inability to boot after updating Openindiana Hipster on MBR
disk installs.
Problem with booting is solved updating to OI hipster osnet-incorporation
0.5.11-2017.0.0.16205 (2017-02-25_1202) with system/boot/loader
1.1-2017.0.0.16205 (2017-02-25_1228) and onwards and reinstalling boot blocks.
Here are some additional technical information and explanations of what
additional issues were:
- The boot programs written into disk boot block areas are read into memory based on
recorded boot program sizes, since the MBR boot record is not updated by "pkg
update" in case of MBR setups, the boot process will not read the gptzfsboot fully
into the memory. This is problem with installboot command.
- The loader partition reading code was built using optimized data sharing, assuming
only one partition is "open" at the time. Unfortunately in case of ZFS this
assumption is not true and as an result, the disk read validation checks did invalidate
the IO requests.
Both issues are now identified, proper updates are available and the package
updates are available in Openindiana Hipster package repository. Instructions
below are provided, to perform the update, while avoiding the issues.
The second issue is about the implementation specific details inside the loader
and updated binaries which implement the fix, once updated binaries are
installed, so no other special activities are needed.
The installboot problem is more complicated. The installboot command update
implements MBR update, to make MBR boot code able to read and load the
partition boot record, and only record gptzfsboot location and size in
partition boot record.
As "pkg update" will always cause partition boot record to be updated, this
change means that gptzfsboot will always be read using correct size. The complication is
about the fact that we can not enforce MBR update automatically, and the MBR update has
to be performed by the operator. The secondary complication is about the fact that
patched installboot command is available only in updated BE, meaning that bootblock
update has to be performed twice.
Who is affected:
Fresh installs with 20161030 OI hipster snapshot usb/ISO using MBR
partition/slice install, using illumos loader
Who is not affected:
Older 20160421 usb/ISO and earlier installs still using GRUB1
Full-disk installs and GPT installs for rpool.
How problem appears:
Problem appears by issuing regular 'pkg update ' procedure, with affect of
having unbootable system after update and restart.
Workaround1 is done right after update, before reboot, so you don't experience
any inability of boot after update, so that nothing happens if you reinstall
loader upon update and BEFORE restart.
Workaround2 is there if you already restarted after update and you have
unbootable system.
Workaround1:
Bootblock update has to be performed twice, after regular pkg update and before
reboot and after reboot again.
-find the name of your new active updated BE:
$ beadm list
--
oi-hipster-87 R / 36.8G static 2017-02-25 19:07
-mount new BE into /mnt dir, so we can install new loader into MBR: (assume
root privileges by su, sudo or pfexec)
$ pfexec bash
# beadm mount oi-hipster-87 /mnt
-Install new illumos loader from new BE into MBR to be able to boot from HD
again:
# bootadm install-bootloader -MfvR /mnt
It is the intented behaviour here that grub stuff is installed here? :
# beadm mount hipster-2017.16257 /a
Mounted successfully on: '/a'
# bootadm install-bootloader -MfvR /a
be_do_installboot: device mirror-0
be_do_installboot: device c4t0d0s0
Command: "/sbin/installgrub -F -m -f //boot/grub/stage1 //boot/grub/stage2
/dev/rdsk/c4t0d0s0"
Output:
stage2 written to partition 0, 281 sectors starting at 50 (abs 32180)
stage1 written to partition 0 sector 0 (abs 32130)
stage1 written to master boot sector
be_do_installboot: device c4t1d0s0
Command: "/sbin/installgrub -F -m -f //boot/grub/stage1 //boot/grub/stage2
/dev/rdsk/c4t1d0s0"
Output:
stage2 written to partition 0, 281 sectors starting at 50 (abs 32180)
stage1 written to partition 0 sector 0 (abs 32130)
stage1 written to master boot sector
You should only do beadm / bootadm operations from new BW with loader,
not from the old BE with grub, but new one with loader.
If not installing illumos loader, grub is kept being used, so do
reinstall loader once booted into new, loader BE.
See
https://wiki.openindiana.org/oi/MBR+reinstall+after+illumos+loader+update
/
https://www.openindiana.org/2017/02/27/issues-with-loader-leading-to-unbootable-systems/
Also, only way to boot previous (GRUB) BE's after installing illumos loader
is to firstly select BE in loader menu (options 6, 3 and number of BE
then 1), Hitting ESC (or beadm activate <ba-name> zfs:rpool ) and:
ok load -t rootfs /platform/i86pc/amd64/boot_archive
ok boot
OR once booted into new, illumos loader BE, you can mount GRUB BE (beadm
mount <ba-name> /mnt )
and install loader into older BE (pkg -R /mnt install loader)
so you can select older BE in loader and just boot.
Just make sure not to use beadm / bootadm commands in older, GRUB BE.
||||
_______________________________________________
openindiana-discuss mailing list
[email protected]
https://openindiana.org/mailman/listinfo/openindiana-discuss
