OpenBSD 7 fails to boot automatically after install .... I need to select my SSD from

[bsd007]

I was using Arch Linux and the boot process was fine. I just installed OpenBSD 7 an hour back. Right after install I rebooted my desktop & it didn't boot to OpenBSD I saw the UEFI screen.

When I looked carefully I found that my SSD is not appearing in the lower right corner. I only see my spinning HDD which I use to store data & my DVD Writer.

But when I press F8 (boot menu key) I see all three devices namely my spinning HDD, DVD Writer & my SSD. When I select my SSD OpenBSD boots normally.

But I need to do this every time I boot.

Why did this happen & how do I fix this ?

[OFF TOPIC] I have taken 2 photos which are inside my /home/username/Downloads but when I try to upload them they wont appear. So is OpenBSD running Firefox inside a sandbox of some kind ?

[jggimi]

I can only guess that your laptop is looking to boot with Secure Boot, used by Windows or Linux. OpenBSD does not use Secure Boot. Secure Boot can be disabled either by BIOS switch or by deleting the Secure Boot keys for OSes no longer installed.



As for your Firefox issue, perhaps you're logged in with a different $HOME than you expected?

[TronDD]

For Firefox, ~/Downloads is one of the few locations it can see. By default, on a new install, I don't think the upload dialog starts there and you can't browse to it because it can't see your home directory. Did you try typing in the path to you Downloads directory to open it?

[Head_on_a_Stick]

Originally Posted by bsd007

I was using Arch Linux

The boot entry for Arch might still be present in the motherboard NVRAM. OpenBSD uses the "removable" EFI loader location and this would be over-ridden by a specific NVRAM entry.

Load up an Arch live ISO image in UEFI mode and run this to list the NVRAM entries:

efibootmgr

Then use this to delete the Arch entry:

efibootmgr -b xxxx -B

Replace xxxx with the boot number assigned to Arch. Zero padding is not required.

You might also be able to delete boot entries from the firmware ("BIOS") options.

Originally Posted by jggimi

I can only guess that your laptop is looking to boot with Secure Boot, used by Windows or Linux.

Arch does not support SecureBoot unless it is explicitly set up by the user.

[jggimi]

Originally Posted by Head_on_a_Stick

You might also be able to delete boot entries from the firmware ("BIOS") options.

That's the only way I've ever done it.

Arch does not support SecureBoot unless it is explicitly set up by the user.

Thanks, I didn't know, as I'm not a Linux user.

[shep]

You can work around this by chainloading OpenBSD from the Arch grub2 bootloader. Grub2 allows you to add boot entries with /etc/grub.d/40_custom. The Operating System is selected from Grub2 rather than the bios.

http://daemonforums.org/showpost.php...4&postcount=20

[jggimi]

EFI multibooting may work, but the OpenBSD Project doesn't officially support it. According to the OpenBSD FAQ:

rEFInd is reported to usually work. GRUB is reported to usually fail. In either case, you are completely on your own.

[shep]

Originally Posted by jggimi

EFI multibooting may work, but the OpenBSD Project doesn't officially support it. According to the OpenBSD FAQ:

In my experience, that statement is misleading. The problems I've had with chainloading OpenBSD EFI come from the removable EFI loader location.

The issue has 2 parts:

1. Redhat, and derivatives use the same removable EFI loader location. When you install OpenBSD, it's BOOT64.EFI replaces the linux iteration and your system boots into OpenBSD. Re-installing/re-configuring GRUB2 then overwrites the OpenBSD BOOTX64.EFI entry and you are back to booting into linux with no OpenBSD access.
2. Moving the OpenBSD boot entry prevents kernel relinking - I think due to a failed sha256 checksum that does not write to OpenBSD's BOOTX64.EFI when it is in a non-standard location.

Debian, Crux, Arch all have their BOOTX64.EFI entry in a non-standard location so they readily co-exist with OpenBSD and it usually does not "fail".

Note that FreeBSD, and NetBSD do not kernel relink on boot and are easy to dual boot with Fedora/Redhat derivatives.

[jggimi]

Would you consider working up a diff(1) to the FAQ to better describe these limitations?

[Head_on_a_Stick]

Originally Posted by shep

http://daemonforums.org/showpost.php...4&postcount=20

The (hdX,gptY) assignation may change from one boot to the next if the system has multiple drives so it's probably best to use the UUID instead, like this:

menuentry 'OpenBSD' {
   search.fs_uuid $uuid
   chainloader /path/to/OpenBSD_BOOTX64.EFI
}

Replace $uuid with that actual UUID of the EFI system partition and use the actual path to the OpebBSD BOOTX64.EFI (relative to the ESP) in the chainloader line.

In my experience GRUB is very good at auto-loading modules so the insmod lines are probably not needed.

EDIT: also note that Arch systems will over-write $ESP/EFI/BOOT/BOOTX64.EFI if systemd-boot is used because bootctl(1) uses the fallback loader location in case of intransigent UEFI firmware implementations.

[shep]

Originally Posted by jggimi

Would you consider working up a diff(1) to the FAQ to better describe these limitations?

I'll try.

I'm guessing the process

1. Download faq4.html
2. Copy to faq4_new.html
3. Make edits to faq4_new.html
4. Run diff faq14_new.html faq4.html

The FAQ itself refers readers to misc@openbsd.org - does misc take attachments or should I submit to tech@openbsd.org?

[shep]

Originally Posted by Head_on_a_Stick

EDIT: also note that Arch systems will over-write $ESP/EFI/BOOT/BOOTX64.EFI if systemd-boot is used because bootctl(1) uses the fallback loader location in case of intransigent UEFI firmware implementations.

I think the $ESP string is a configurable option:

OPTIONS
The following options are understood:

--esp-path=

Path to the EFI System Partition (ESP). If not specified, /efi/, /boot/, and /boot/efi/ are checked in turn. It is recommended to mount the ESP to /efi/, if possible.
--boot-path=

Path to the Extended Boot Loader partition, as defined in the Boot Loader Specification[1]. If not specified, /boot/ is checked. It is recommended to mount the Extended Boot Loader partition to /boot/, if possible.

[Head_on_a_Stick]

The --esp-path option just tells systemd-boot where the ESP is mounted.

Here's the relevant section:

install
Installs systemd-boot into the EFI system partition. A copy of systemd-boot will be stored as the EFI default/fallback loader at ESP/EFI/BOOT/BOOT*.EFI. The boot loader is then added to the top of the firmware's boot loader list.

EDIT: it might be best if @admin could split this discussion out because I think the OP has actually removed Arch and doesn't want to multi-boot at all.

[J65nko]

Originally Posted by shep

I'm guessing the process

1. Download faq4.html
2. Copy to faq4_new.html
3. Make edits to faq4_new.html
4. Run diff faq14_new.html faq4.html

You can download from the CVS web interface: https://cvsweb.openbsd.org/cgi-bin/c.../faq/faq4.html

And IIRC they want an "unified diff"

[jggimi]

Originally Posted by shep

The FAQ itself refers readers to misc@openbsd.org - does misc take attachments or should I submit to tech@openbsd.org?

I know I've seen diffs in misc@ but they may have been submitted inline rather than as attachments.

If you go with an inline diff, send it to yourself first, and test it with patch -C to ensure it doesn't get munched by your sending mailer.


---Edited to add:


Looking through marc.info, I can see attachments in misc@ mailings.

[jggimi]

The Project website, like the rest of the OS, is managed via CVS. The website has its own "www" repository. If you're comfortable with using git; there is an official github mirror at https://github.com/openbsd/www which you can clone; git-diff(1) output can be directed to a file and emailed as an attachment.