Installer Freezes

[myway_1]

More info. I burned the installer image to a microSD card so that I would not need to use the USB hub. Still unable to proceed because it actually turns the USB port off, so I still couldn't use my USB keyboard plugged directly into the PC. I took a video with a faster phone and here is the entire dmesg(8)

[myway_1]

[jggimi]

The key message is in your last photo:

uhub0: device problem, disabling port 1

There is another message which appears in the first image, before the dmesg begins:

kbc: cmd word write error

This message is from the pckbd(4) driver - that is the kernel's PC/AT keyboard controller.

It is difficult to read this dmesg(), but nothing else from it pops out at me.

1. You may wish to report this to the Project -- as ocicat mentioned previously, this is not an official support channel.
2. You may want to install the system using other mechanisms, as I'd previously suggested, and learn if a GENERIC kernel has the same uhub(4) issue or not.

I have no other suggestions for you. There is a USB subsystem analysis tool -- usbdevs(8) -- but it requires both an installed system and -- if not network connected -- a functional keyboard.

[LeFrettchen]

kbc: cmd word write error

Looks similar to this : http://openbsd-archive.7691.n7.nabbl...-td264684.html

[jggimi]

Yes, the keyboard controller driver issues the message because there is no keyboard controller hardware.

[myway_1]

I have never used a virtual machine. I suppose it's not too difficult to learn.

I don't have access to another computer of the same architecture.

I just want to be able to install any BSD OS without having to jump through lots of hoops.

I'm getting tired of the problems that this Intel Compute Stick is causing. I got it new for $45 a couple of months ago, but even at that price it hasn't been worth it. Only about one in three linux distros will install onto it.

The combination of UEFI boot with no compatibility mode, 8 GB eMMC internal drive, 1 GB of RAM (not expandable), only 1 USB port, no ethernet port and a wifi chip that requires restricted proprietary firmware makes it tough to use. No wonder they have had to dump it on ebay for cheap.

[jggimi]

I will create a pre-installed UEFI-bootable OpenBSD/amd64 image for you, which you may download and "dd" onto any handy USB stick. I will use -current, the development branch of the OS, to ensure you have the most up-to-date kernel. And, as the Atom Z3735F is quad-core, it will boot the GENERIC.MP kernel.

Expect a message from me with a link in approximately 10 hours, which is when I will be able to prepare this for you.

[myway_1]

Originally Posted by jggimi

I will create a pre-installed UEFI-bootable OpenBSD/amd64 image for you, which you may download and "dd" onto any handy USB stick. I will use -current, the development branch of the OS, to ensure you have the most up-to-date kernel. And, as the Atom Z3735F is quad-core, it will boot the GENERIC.MP kernel.

Expect a message from me with a link in approximately 10 hours, which is when I will be able to prepare this for you.

Thanks so much for this generous offer.

Once I have it on a USB stick, will I be then able to install it from there to my internal eMMC drive? (barring unforeseen difficulties)

[jggimi]

My plan is to provide you with a small test image, of a couple hundred megabytes in size.

Test 1: Plug the stick and your keyboard into the your hub. Can you boot it directly? Does it complete the boot and does the keyboard work?

Test 2: dd(1) the image on to your mSATA drive, after carefully backing up what's on the mSATA drive, of course, including its GPT and boot blocks. Using dd(1) from Linux may be an easy way to ensure you have a good, complete disk image. And when writing the test image, you'll need to find a way to not be using the mSATA drive at the time you do this step. One way would be to boot some sort of Linux rescue system from USB. Note that depending on the EFI "BIOS" and prior EFI installations, you might also have to clear prior boot records from the EFI menus in order to successfully boot after writing new boot blocks. After all that, does the OS boot and does the keyboard work?

If Test 1 works, I would assume Test 2 should also work, barring any EFI boot complexities (and there are plenty). Test 2 might work even if Test 1 fails, but I would expect the odds of success would be much lower.

If tests are successful, only then do we need to worry about provisioning a "production" image for you.

Please note: at the moment, multibooting OpenBSD on EFI systems is not supported by the Project, though DaemonForums member bceverly has succeeded in getting it to work. I recommend not worrying about multibooting with OpenBSD unless and until you can get it to operate successfully.

[myway_1]

I don't know how to do much of what you describe in test #2, but there is nothing that matters on the internal eMMC drive. Just the linux OS that I can reinstall in a matter of minutes. I keep all data on a USB HDD. So if the simple way would be to use a live USB linux to delete / format the internal drive, that will be fine.

[jggimi]

Windows, and some Linux systems can be installed on EFI systems with Secure Boot. If that has been deployed, there will be matching records in your hardware's EFI/BIOS boot menu.

While I don't use Linux, I have installed it once or twice, and I recall installing Ubuntu with Secure Boot. It adding a boot menu record called "Linux" which I needed to delete before I could install and boot anything else from that drive.

--- Just to set reasonable expectations ---

Test 1: booting to see if a GENERIC kernel resolves the USB hub issue. Odds of success: low, but not impossible. My guess - 5% odds of success.

Test 2: booting to see if the internal drive can be used for an EFI boot of OpenBSD. My guesses - 95% odds of success if Test 1 was successful, 5% odds of success if Test 1 failed. This means having Test 1 fail and Test 2 succeed: 0.25% overall odds of success.

[myway_1]

I have had secure boot turned off from the very beginning. This PC has never had Windows on it. It shipped with Ubuntu.

[LeFrettchen]

Scott Bonds tried and succeeded installing OpenBSD on a Intel Compute Stick...
Not the same stick, but could help...

Source : https://www.mail-archive.com/misc@op...msg146577.html

[myway_1]

I don't know if this makes a difference, but it's not the USB hub that causes the problem. I "burned" the install image onto a microSD card for a seperate trial, put the microSD card into the PC's microSD card slot and booted with the hub disconnected. The result was the same - the USB port was shut down. I even tried removing the USB keyboard dongle immediately after starting the boot process so that the USB port was empty. Same result.

[jggimi]

And myway_1 has also tested a GENERIC kernel, and received the same uhub(4) error.

[myway_1]

Another aspect of my PC is that even though the CPU is 64 bit, the UEFI is 32 bit. So it needs a mixed-mode UEFI. OpenBSD installer boots, so I guess it has that covered?

In regards to the uhub error, perhaps that has to do with the USB root hub, not a physical USB hub. When I do a linux lsusb command with the physical USB hub not connected, it outputs three items:
the USB keyboard dongle
the Intel root hub
the Linux root hub

[jggimi]

Mount and look through the FAT-formatted EFI filesystem, and you will see both 32 and 64-bit bootloaders. However, the OpenBSD 32-bit OS, i386, is not yet supported with EFI boot.

[jggimi]

And yes, the uhub(4) complaint appears to be about the built-in, Intel EHCI hub.