No hard drive detected on Linux install

I was finally fed up with not being able to render my Blender projects on the GPU, just because there was not enough memory on the card, and some other quirks my computer developed over time. In addition to that it was high time to upgrade the hardware and start on a clean installation.

The purpose of Rendering has driven the decision to chose a good graphic card, that is affordable, built in a PC from a shop where I do have an account. The result is the gaming machine Predator 9000 with a NVIDIA GeForce GTX 1080 Ti with 11 GB VRAM.

This being a gaming computer came with Windows 10 preinstalled. So after some rudimentary update and configuration of that system, I went around to install a Linux Mint KDE in dual boot.

Did not work. First issue was an error related to ACPI, for which the bios firmware did not supply driver, so I had to turn them off with the boot parameter:

 acpi=off

During the startup there were some curious error messages relating to SATA, but the life system came up (although in really low screen resolution). Installing however failed because there were no hard drives detected. parted -l as well as fdisk -l reported no drives besides the USB stick from which I booted.

So, searching the internet brought up some issues, that lead me to the conclusion that the cause is somewhere in the Bios (or UEFI as it is now called). Turning off secure boot did not change anything, but was recomended never the less.

As there were errors relating to SATA, I switched the „On Board SATA Mode“ from „RST Premium with Optane“ to AHCI and suddenly the Linux life system did detect both hard drives (one SSD one disk). However Windows is no longer bootable. Switching the mode back will allow Windows to boot.

The solution to this issue is documented in this post.

While this allows the installation of Linux on a harddrive, I was then not able to boot into Linux as the firmware boot manager always chooses the Windows Boot Manager to start. According to this question/answer this seems to be worsened by some motherboard manufacturers only provide minimal UEFI implementations in their firmware and do not allow to select any boot options (other than the boot order and the device) in the BIOS. Reading up on this lead to lot’s of posts that suggest to use bcedit to configure the bootmanager. For me this does not work, as I am unable to place the grub boot manager as first entry in the firmware boot manager and make it stick.

Taking a look at the different directories in the EFI files system there are:

  • Boot
  • OEM
  • Microsoft
  • ubuntu

I am unsure what the Boot folder is for, it was my impression, that this would contain the first bootloader to be used and then delegating to the Microsoft bootloader, however replacing the bootx64.efi file there with the one from ubuntu (grubx64.efi), by renaming, did not have an effect. However replacing /Microsoft/Boot/bootmgfw.efi with the grub one brings up the grub bootloader. However Windows 10 is no longer bootable (as the bootloader points the grub bootloader and Linux does not start at all. From the file naming I would assume that this file is the Boot Manager of the FirmWare.

This lead me to the next attempt by aproaching this issue with rEFInd. Hoewever installing proves difficult, as it is not possible from a live linux version and under Windows the EFI filesystem cannot be mounted correctly. This leaves the manual installation through the shell, which of course is not available and has to be installed first. So first things first: doing a testrun with the CD-image of rEFInd.  This let’s me start Windows and I get an option to startup Linux Mint which hangs itself then with:

fb: switching to nouveaufb from EFI VGA

This seems to be another issue with poor firmware implementation. The solution there is to add nomodeset in the boot parameter, as the firmware as well as the Linux installation do not support the graphics card (GTX 1080 Ti). This would also explain why the installation happen in low resolution. Installing the Nvidea proprietary drivers resolves this problem. With Linux booting now with the help of rEFInd, it should then also be possible to install rEFInd as default Boot Manager, whithout going through the shell.

Just installing rEFInd does not work, as the bios firmware still picks the boot manager for windows, but with this setup it should be possible to do some renaming and rEFInd will still find the boot manager for windows.

With hindsight there is probably an easier way than the described below:

When starting Linux the EFI partition is mounted under /boot/efi, which makes life a bit easier. All path in this setup have the root there, so / is actually /boot/efi/. First I renamed the the /Microsoft/Boot/bootmgfw.efi to win10mgf.efi (not sure if this was necessary, but I wanted to make sure that there are not two files named the same). Then I renamed /Microsoft ro /Microsoft_renamed. I created a new directory /Microsoft and moved the /refined folder in there and renamed it to /Microsoft/Boot. Then I renamed the refind.efi to bootmgfw.efi. This is required as the firmware boot manager searches on the EFI partition for /Microsoft/Boot/bootmgfw.efi. With this setup I got a boot loader menu by rEFInd with entries for grub, boot-rescue and Linux Mint. With delete I hid the boot-rescue option. From this menu, Linux is bootable directly as well as through Grub. Windows is only available as option through Grub, but not bootable.

The issue there is that the boot menu entry is generally generated by the os-prober and points to the rEFInd efi. To fix this, disable os-prober in /etc/default/grub.d/linux.cfg:

GRUB_DISABLE_OS_PROBER=true

Then you create a custom entry in /etc/grub.d/40_custom by copying the original entry generated by the os-prober in /boot/grub/grub.conf (all the way down) and replace the path /EFI/Microsoft/Boot/bootmgfw.efi with /EFI/Microsoft_renamed/win10mgf.efi (or whatever you renamed it to). Now Windows is bootable through grub.

Alternative approaches for Maps with primitive values

While profiling the current state of OpenPatrician I noted that there are maps that are quite memory intensive and they have primitive values. As the map cannot hold primitive values they need to be boxed into their corresponding object, which adds overhead. Therefore I asked about alternative approaches. To figure out what meets my requirement best I did a small benchmark of my own comparing some of the available collection libraries.

„Alternative approaches for Maps with primitive values“ weiterlesen

Evaluate Bezière curve

One of the tasks for the coming release of OpenPatrician is a better representation of the price development of wares with respect to the amount that is available. The idea is to define the curve visually and then transform the parameters of the curve into a formula that allows the computation of the price of the ware, given an available amount.
A natural choice for that is to define the curve as a Bezière curve with is very intuitive to tweak until the curve looks the way you want.

„Evaluate Bezière curve“ weiterlesen

Documentation generation with the Compiler API

Documentation of code has a tendency to become obsolete quickly. For that reason most often the only documentation is the code itself and if you are lucky some JavaDoc that is more or less up to date. For that reason I already started some time ago to generate additional documentation by doing static code analysis on my OpenPatrician project. So far this was done mainly with the Reflection API and it was sufficient to figure out what Spring beans there are and where they are used.

The next documentation task was to figure out which class posts what event type on which EventBus and which class handles the event. Or more simple what are the Event producers and what are the Event consumers and mapping them to see how the event messages flow. As the publishing of the events (in the terminology of Guava EventBus ‚post‘) happens within a method, simple reflection will not yield the desired results. Therefore I turned to the Compiler API that can be found in the tools.jar. As that API is poorly documented by JavaDoc and there are not that many examples, I decided to write this post as a means to provide another example.

„Documentation generation with the Compiler API“ weiterlesen

Serializing Java Objects

There are various ways to serialize Java Objects. This be came an issue for me in the context of the save game feature for OpenPatrician. So it was clear from the start that the output format should be XML. As The project already uses JAXB to generate some classes from XSD this seemed to be an obvious choice. Another option turned out to be XStream.
„Serializing Java Objects“ weiterlesen