Cannot boot after successful install of 5.8

[avallee]

Hello,

So I wanted to give OpenBSD a try some days ago.

Install went smoothly, I chose the default option pretty much everytime (whole disk install, auto layout, etc...)

Except that now I cannot boot anymore. I just end up with a black screen, blinking cursor. I can't even access the BIOS setup anymore, the hang appears before entering the setup. The only way left to boot or access the BIOS setup is to unplug this mSATA SSD. I tried on multiple disks, same result.

I catched some comments on various forums that would imply this may be a BIOS bug, due to how OpenBSD setup the MBR (or GPT?), so I tried to upgrade my BIOS (AMI) without any improvements.

Does anyone have some inputs/ideas on this? Maybe it's a problem that is triggered only on some BIOS, but that should be possible to circumvent by OpenBSD. Maybe some bug tracker issue somewhere or in the release notes/commit logs? I can't find anything related to this anywhere.

Any help would be greatly appreciated, I'm desperate to find a solution, and would really love to give OpenBSD a try.

[TronDD]

Can you give us some idea of what system you have?

Someone had problems on misc@ where, if I remember correctly, the BIOS needed some data on the disk to boot.

With my Lenovo x250, with USB3 enabled, I can boot off the internal drive, but can't access an external USB drive. With USB set to Legacy mode, I can boot from the external drive, but not from the internal drives...

Could be several things...

Tim.

[avallee]

Thanks for the answer!

I have a laptop from Schenker Technologies, an XMG P503 PRO.

The motherboard is a Clevo P15SM. The BIOS is from American Megatrends (AMI). I have the latest BIOS (1.03.05), EC, EM updates.

In the BIOS setup, I disabled UEFI, disabled Rapid Boot, disabled Intel Anti Theft, activated BIOS/MBR mode. I naturally tried various combinations of these.

OpenBSD is installed on a 256GB mSATA-III SSD SanDisk X110 (SD6SF1M-256G).

Processor is a core i7 4900MQ.

[avallee]

I have the feeling my problem is the exact same as these guys (they used 5.6):
http://comments.gmane.org/gmane.os.openbsd.misc/218633

When I tried to turn on again, the system didn't boot. I discovered that it only worked if I remove the hard drive. It sucefully downloaded and installed everything, so I rebooted the system to boot my new fresh install.the system don't boot as before, I can't open the bios as before

Similar issue on a DELL XPS 13" Developer edition I got
back in June -- ran fine with ubuntu as shipped with Dell, and then I
wiped and installed OpenBSD and now can't even access the BIOS.

I'm *sure* it's a BIOS issue as the BIOS is probably trying to do
something silly with the hardisk. Haven't gotten around to flashing the
BIOS to a newer version as I'm fairly sure
I'll need to remove the harddisk before the system will even let me
boot (and that involves taking apart most of the laptop)

The Dell had no problem booting the install media from usb, was just
when it came time to try and boot from HD that the BIOS freaked, and now
won't allow me to access the BIOS settings or the "choose which media to
boot from" menu.

I've got a Dell latitude E5440 that exhibits the same problem.

Got exactly the same issue with my Acer Aspire v5-573G several months ago.
Drove me crazy like hell. Nice to know that I wasn't the only one facing
this problem. Updating Acer BIOS didn't help, I had to remove HDD from
SATA-connected slot altogether to be able to boot past BIOS check.

Following on these guys that mention they have a problem with a Dell XPS, i found other people on internet with the same problem: https://lobste.rs/s/mnmcnn/4th_gen_d..._now_available

Yeah another caveat… if you try to install OpenBSD watch out… I’m unable to even get into the bios setup screen after wiping my internal disk. Possible that it requires a dos mbr, but I haven’t had a chance to try that yet. Only way for me to get the machine working again is to pull out the MSATA ssd.

The current theory on this is that OpenBSD doesn’t erase the GPT fully, and the bios continues trying to read it, then crashes. This should be fixed in 5.7 and current snaps.

Could that very last sentence be a clue to solve the problem? Is there any knowledge of this bug in OpenBSD somwhere? The guy seems to imply that it was solved in 5.7, but I used 5.8 and I have the same symptoms (maybe not the same root cause, but...)

[jggimi]

If you are willing to test again, I recommend testing with a -current snapshot rather than 5.8. That's because there's a lot of work being done on EFI booting support. That development is still underway, but there's been a lot of changes to supporting utilities (such as fdisk(8), which has now received changes to manipulate GPTs) than there was when 5.8 development ended.

If -current has the same problem, I recommend reporting the issue to the bugs@ mailing list.

You might consider posting about the issue to the misc@ mailing list, too, but bugs@ will be seen by more developers. Something like half of them don't follow misc@ -- or ... don't participate there.

[avallee]

So I just tested with -current.
Result is exactly the same.

But I noticed something. I unplugged the mSATA disks to format them on another computer, through a mSATA/USB adapter. I just tried to boot from these disks via USB and it worked!

So the very same disks cannot boot through mSATA (internal), but works perfectly fine through mSATA -> USB.

This is the case for all my disks (different brands, sizes) and through different internal mSATA slots.

Now that I mention that, I remember that some guy mentioned the very same behavior (with a totally different computer) in the thread mentioned above:

Got exactly the same issue with my Acer Aspire v5-573G several months ago.
Drove me crazy like hell. Nice to know that I wasn't the only one facing
this problem. Updating Acer BIOS didn't help, I had to remove HDD from
SATA-connected slot altogether to be able to boot past BIOS check.
Interesting observation, though - USB-booting worked without a hitch, both
from a flash drive and from the same HDD connected externally through
SATA-to-USB converter. I hope this helps with further investigation.

[jggimi]

Whatever it is, it isn't mSATA-specific, because I'm posting from a 5.8-stable system booted from and running on an mSATA connected drive at the moment.

sd1 at scsibus1 targ 2 lun 0: <ATA, TS32GMSA370, N112> SCSI3 0/direct fixed t10.ATA_TS32GMSA370_C528390021_ 
sd1: 30533MB, 512 bytes/sector, 62533296 sectors, thin

There's something else in the hardware/BIOS event-chain involved with this particular problem. mSATA is a contributing factor, perhaps, but is not the root cause.

[jggimi]

I've been thinking. Now that you have access to the sector contents (via USB), you could dd(1) the leading sectors to a file for analysis. It is possible that you may find an indicator of why an otherwise valid MBR will boot from USB but not from ATA.

----

Edited to add:

It's a long shot. It could very well be that BIOS emulation is broken on these machines, and they require EFI boot from ATA connected hardware.

EFI boot is possible, with -current, but it requires some jumping through hoops.

This "howto" may not be up to date, as EFI boot is very much a moving target.

https://blog.jasper.la/openbsd-uefi-bootloader-howto/

[kungfucha]

Just had a similar experience, had been trying OpenBSD in a vm and enjoying it. Decided to give it a fair crack on my ssd on bare metal. Used the 5.8 iso on a dvd. Went along with most of the defaults aside from keyboard uk, rebooted and got stuck in either the motherboard bios/uefi. I managed both to get stuck and also an endless bios/uefi loop.

The only way out was when I eventually opened up the box and disconnected the sata.

Now I'm running funtoo on a spare drive, can't boot with the ssd connected, and can't access it if I connect after boot from systemrescuecd or funtoo.

Hardware:
Intel 4130 Haswell
Gigabyte HD3-Z87
Crucial Tracer DDR3 4G RAM
Samsung 120GB 840 EVO

Samsiug ssd was running gpt/lvm/luks Arch install, OpenBSD attempt was plain, no encryption/lvm.

A little worried the OpenBSD install has killed my ssd, help or pointers would be appreciated.

*edit* gotta pick up a sata to usb adaptor, thanks

[jggimi]

I'm sorry you're having trouble. Welcome! I'm not sure I can help from all the way over here on the other side of the Internet. There's nothing particularly special about an OpenBSD installation on an MBR-capbable architecture. However, there appear to be BIOS emulators that have trouble with it on certain EFI machines.

A typical installation deploys an MBR in LBA #0. Those 512 bytes contain a typical boot program, then a four-slot primary partition table, and the MBR 0xAA55 magic number .

The first three slots are unassigned, and the fourth slot contains the OpenBSD partition definition. That fourth slot is flagged as active (bootable), and the MBR pogram will load the PBR from the first LBA of that partition.

It's my guess -- and its only a guess -- that some firmware programmer decided they could interpret an MBR without following the decades-old standard. Perhaps it's because they expect an active partition in the first slot. If that's true, there isn't anything in the first slot (partition 0 if you're counting 0-3, or partition 1 if you're counting 1-4).

The only way to confirm this would be to edit the MBR and swap partition slots (0 with 3, or 1 with 4, however you prefer to count them), and see if the problem goes away.

To test that will require mounting the disk drive in some other hardware, such as a system that has an actual BIOS in it.

It's always possible that the vendor has noticed the error, and cared enough to publish updated firmware.

[kungfucha]

Cheers, will check if my motherboard firmware is up to date, not checked for updates for a year or so.

Failing that I'll drop by the pc repair shop round the corner and see if he can wipe/format it. I don't have a sata to usb adaptor but that's plan C.

Feeling a little more confident it's more mbt/gpt/uefi/bios issues than dead ssd but time will tell.

[jggimi]

Good luck. My guess was just that: a guess. On machines with a BIOS, the MBR program is loaded into RAM and then executed. EFI machines are different, they emulate a BIOS when booted in legacy mode.

EFI booting and GPT support are both in active development. That may be a solution for your hardware, but not all the pieces of the puzzle are completely in place yet... and those that are in place now are subject to further operational revisions.

[shep]

I have had similar issue installing on a hard drive that previously had a GPT based (Debian or FreeBSD) boot loader. The OpenBSD install would go flawlessly, but then fail to boot.

In contrast to a traditional MBR boot loader, A GPT boot loader occupies the first TWO sectors and often writes a boot table that extends past the first sector into the second sector.

From gdisk Authors Web Site.

Because the basic MBR data occupies just one sector, compared with several for GPT, using an MBR-only partitioning tool can leave the disk with both valid MBR data and mostly-intact GPT data.

One of the above posters was installing over an prior Ubuntu installation and likely has some remaining GPT data.

gdisk is included in GParted. Download and boot Gparted to the command line. Run gdisk on your mSATA. If gdisk finds left over GPT information, it will let you know.
gdisk /dev/sd***
Replace the *** with your mSATA drive ID.

If you want to wipe it clean and start fresh, follow the instructions on the gdisk web site.

Whenever I have had a new OpenBSD install that will not boot, using gdisk to zero out the GPT and MBR, followed by a new OpenBSD install, for me always results in an OpenBSD system that boots.

[kungfucha]

The sata to usb adaptor done the job, but I didn't get to spend any time investigating what happened.

I borrowed a usb to sata, connected it in situ, used fdisk to remove partitions, created one new partition and all is well. I
can boot into my funtoo system fine and access the ssd again. Planning on shuffling things around, giving the insides of the machine a much needed clean and picking up some sata to usb cables shortly.

[jggimi]

I'm posting a reply to this thread to note that the problem with "bricked" systems after installing OpenBSD is related to a facility called "Intel Rapid Start" which needs to be disabled if, in the words in a post in the misc@ thread, the operating system is "...not sufficiently micro and soft." Disabling this feature permits both BIOS and EFI booting.

It's a long discussion, but the solution starts here: http://marc.info/?l=openbsd-misc&m=146233640812188&w=2