[OpenIndiana-discuss] [HEADS UP] Issues with loader leading to unbootable systems

[Carsten Grzemba]

On 21.03.17 10:56, Carsten Grzemba  <grzemba at contac-dt.de> wrote: 
> 
> 
> 
> On 27.02.17 08:42, Alexander Pyhalov <alp at rsu.ru> 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
> 
Grub install was correct because I had a config in /etc/default/be with:
BE_HAS_GRUB=true