Pop!_OS Linux Fixing Windows Dual Boot Problem

In a previous blog post I have mentioned that I was not able to add my Windows 10 installation to the Grub boot menu. I have finally found a solution. Now, in my last Linux blog post I mentioned that I ultimately gave up on Linux after trying Ubuntu 20.04. Well, I could not stop thinking about it. I am on Pop!_OS again and although I did not disconnect any SSD on installation, Pop! did not detect Windows 10 and add it to Grub itself. So, I was back at where I started.

Quick recap of the setup: I have two SATA SSDs (yes, SATA, like a cave man), one with Windows 10 (the Crucial MX500) and one with Pop!_OS Linux (the Samsung 850 Evo). The bootloader for each OS is on the respective SSD.

Now, enough background, let us get to the solution!

If you are CLI wizard do your thing, I will be using a convenient UI for the first step. Open “Disks” and locate the Windows 10 EFI partition. It’s around 100MB in size. Once you have found it, click the “Play” button to mount it.

The Disks utility will then display the mount point that is required in the next step.

Now, copy some Windows 10 Boot files to your Linux /boot folder. Yes, you read that right. Sounds weird, but it did the trick.

Do this with Nautilus or use the following command (which I recommend). Replace <mount point> with the path you got from the Disks utility. Note that path completion does not work once you go past /boot/efi. The EFI folder exists, you merely do not have permissions to see it as a regular user.

sudo cp -r /<mount point>/EFI/Microsoft /boot/efi/EFI

The last step consists of making the boot menu show up so you can actually select an entry. Edit loader.conf and add “timeout 10” (or any amount of seconds you prefer).

sudo vim /boot/efi/loader/loader.conf

All you need to do now is reboot and (hopefully) enjoy a boot menu with your Pop!_OS and Windows 10 boot entries. I do not know if this procedure also works with other Linux variants. It might for the Ubuntu based distributions, but I cannot say.

Maven Failsafe Plugin environmentVariables Not Working (org.postgresql.Driver claims to not accept jdbcUrl)

A few months ago I had written about how one can setup a PostgreSQL database in a docker container during the Maven testing phase (part 1 and part 2). Today, I wanted to iterate on this topic using Testcontainers. Unfortunately, before I could get to that I ran into issues with the original project. For some reason I was now getting the following error:

Caused by: java.lang.RuntimeException: Driver org.postgresql.Driver claims to not accept jdbcUrl, jdbc:postgresql://localhost:${it-database.port}/docker_db_testing_tests

Maven did not replace the variable it-database in the integration test application.properties file. The question is: "why now"? It has worked before. Now, one thing that I changed is that this time I was using Linux instead of Windows. Either way, the fix was simple, although not obvious. It seems to be an issue with the Maven Failsafe plugin.

Not working:

<configuration>
    <environmentVariables>
        <it-database.port>${it-database.port}</it-database.port>
    </environmentVariables>
</configuration>

Working:

<configuration>
    <systemPropertyVariables>
        <it-database.port>${it-database.port}</it-database.port>
    </systemPropertyVariables>
</configuration>

Here is the link to the commit.

Spring Multipart File – Can I Read InputStream Multiple Times?

The short answer is Yes.

Here is the long version and why I even asked myself this question.

If you are familiar with ServletRequest then you probably know that calling its getInputStream method only works once. If you need to read the body data multiple times then it is up to you to cache it in a buffer or employ workarounds such as a "caching servlet request". Unfortunately, this fact is not stated in the Javadoc of ServletRequest#getInputStream so it is no wonder this question gets asked.

Spring’s MultipartFile is a bit different here. It, too, has a getInputStream method, but this one can be called multiple times. Again, it is not obvious from the documentation which is why I am making this mental note for myself and others who are researching this question because they know about the behavior of ServletRequest and assume – as I did – it is the same for MultipartFile. Fortunately, it is not.

In my case I needed to compute a hash of an uploaded file and then move the file to Azure’s Blob Storage. The Azure API used an InputStream and I assumed, once I had consumed the multipart InputStream that I could not use that API anymore.

As a side note: Using DigestInputStream it is possible to do this in one go, move the data to storage and while doing that compute the hash. In my case, I needed the hash first to compare it with a value that was provided on upload. Only when they match can the data be transferred to storage.