After a boot failure due to a failing spinning disk, both 750GB spinning
disks on my M6600 laptop, were replaced with two 1TB SSD's.
At the time of the failure, OpenBSD -current was, and had been for a
number of years, the only OS installed on a GPT partition on /dev/sd1.
Using a downloaded signify ..., valid install77.img file, I installed
OpenBSD only on a pristine /dev/sd1. Likewise, Windows 10 Pro only, was
installed first, as the only OS on /dev/sd0, using a USB stick.
OpenBSD -current does install but does not create a boot option in the
UEFI boot options. However, the *.EFI files seem to be present.
More than once, I have installed:
- as per all defaults for a GPT install;
- as per custom GPT partitions, 1 512MB for EFI Sys, and 1 for
OpenBSD using all of the remaining diskspace.
Entering UEFI/BIOS setup after the above failures, I have not been able
to manually create a correct UEFI boot option.
Using the install77.img USB stick, dropping to a shell ASAP, then
creating /dev/{sd0,sd1}, then:
# mount -t msdos /dev/sd1i /mnt
I have found these files:
/mnt/efi/BOOT is a directory storing
BOOTIA32.EFI 133120 bytes
BOOTX64.EFI 151040 bytes
/mnt/efi/openbsd is a directory storing
BOOTX64.EFI 151040 bytes
An install can be performed without error using a legacy BIOS partition.
However, if possible I would prefer that all OS's are installed on GPT
partitions as they have been in the past.
Questions:
1. Could recent kernel changes in the UEFI partitioning area be related
to the above install failures?
2. Is it possible to access and manually install the entire OpenBSD
boot variable from within an installed but unbootable OpenBSD, by
dropping to a shell as above?
3. What if any, further useful information should I provide?
Regards,
Avon
--
aer
