Linux Dev Space

Connecting to WireGuard VPN Tunnel

2022-04-01T18:30:00+00:00

This guide provides the minimal first-step instructions required to connect to any WireGuard based VPN server. If you also want to set up your own WireGuard server, you may start by reading the official quickstart guide.

I’ll be using a free-to-use, WireGuard based VPN service, SecurityKiss. They provide a limited free plan and affordable paid plans. No email registration is required to use it. The same steps should apply to other WireGuard based VPN servers as well.

Start by downloading a VPN client configuration file from securitykiss.com/download

The downloaded file would contain the following details.

[Interface]
Address=<interface-ip>
PrivateKey=<client-private-key>
DNS=8.8.8.8

[Peer]
PublicKey=<server-public-key>
Endpoint=<server-public-ip>:7668
AllowedIPs=0.0.0.0/0,::/0
PersistentKeepalive=25

SecurityKiss would generate all the placeholder values including the private key. So you don’t have to make any modifications to the downloaded config file to be able to use it.

Then install the WireGuard client. wireguard meta package include command line tools required to connect to WireGuard VPN servers.

sudo apt update
sudo apt install wireguard resolvconf

resolvconf is internally used by wireguard to set the interface’s DNS servers specified in the configuration file.

Copy or move the config file to /etc/wireguard/

sudo cp US_New_York_1.conf /etc/wireguard/

Then to connect to the VPN tunnel:

sudo systemctl enable wg-quick@US_New_York_1

Make sure to replace US_New_York_1 with the name of your configuration file.

This will brings up a new network interface with properties supplied in the given configuration file. The name of the network interface would be as same as the name of the configuration file.

systemctl enable is used to make wg-quick.service start at boot.

To find the details about the newly added network interface, run:

ip address show
ip address show US_New_York_1

Error Handling & Retry with Apache Beam and Flink

2022-03-26T18:30:00+00:00

This guide discusses one of the approaches to retry errors when running Apache Beam applications with Apache Flink. While the approach discussed here could be applied to any Beam pipeline in general, decide and settle on an error handling strategy that suits your use case.

Apache Beam pipeline may throw exceptions while processing data. Some of these errors are transient (e.g., temporary difficulty accessing an external service), but some are permanent, such as errors caused by corrupt or unparseable input data.

Error Types

Non-Transient Errors (Permanent)
Transient Errors (Temporary)

The diagram below illustrates a sample pipeline that reads data from an input stream, does some transformations, and writes data back to a data sink. Transient errors are handled using a checkpoint-based restart strategy, while a dead letter queue approach is used to handle non-transient errors.

Since a non-transient error will continue to occur as long as it is not corrected, there’s no point in retrying such errors. Beam’s DoFn instances process elements in arbitrary bundles. If an exception is thrown for any element in the bundle and it is not caught, it’ll cause the Flink job to be restarted. Flink runner then has to recreate the operators. The states of these operators will be restored from the last successful checkpoint. For example, the read offset of the recovered source operator will then have a safe offset to restart from. When running in streaming mode, unless a retry threshold is set, a bundle including a failing item will be retried indefinitely, which may cause the pipeline to permanently stall. So it is a must to catch all non-transient errors.

Handling Non-Transient Errors

Handling with a TupleTag

In this approach, exceptions caused due to non-transient errors should be caught within the DoFn.ProcessElement method. And we’d log the errors as we normally would. But instead of dropping the failed element, branch the outputs to write failed elements into a separate PCollection object as follows.

void processElement(ProcessContext c) {
    try {
      c.output(objectMapper.writeValueAsString(c.element()));
    } catch (Exception e) {
      LOG.severe("Failed due to non-transient error {} - adding to dead letter queue", c.element(), e);
      c.sideOutput(deadLetterTupleTag, c.element());
    }
}).withOutputTags(successTag, TupleTagList.of(deadLetterTag)));

These elements can then be written to a database, or a message queue for later inspection, by using another transform.

outputPCollectionTupple.get(deadLetterTag)
      .apply(new WriteToDeadLetterQueue());

Handling with Beam’s WithFailure

WithFailure is a type of exception handler provided by Beam for writing transforms that can handle exceptions raised during the processing of elements. The exception handler would receive an object of type WithFailures.ExceptionElement as the input along with the original input element that was being processed when the exception was raised. WithFailure may not be suitable for transforms that may throw both transient, and non-transient errors. Since it would catch every type of exception, we won’t be able to utilize Flink’s retry capabilities even to retry transient errors.

Transient Errors (Temporary)

The DoFn’s may fail due to transient errors such as temporary outages, or exceptions thrown due to external service failures. Instead of catching such exceptions (dead letter queue approach), we could let Flink retry such failed operations.

When a failure happens, Flink needs to restart the failed task and other affected tasks to recover the job to a normal state. Restart strategies and failover strategies are used to control the task restarting.

Checkpointing should be enabled explicitly, otherwise “no restart” strategy is used.

When checkpointing is enabled Flink would recover the state from the last successful checkpoint. By default ‘fixed-delay’ restart strategy is used for streaming jobs, with infinite retries every 10 seconds.

The following pipeline options are provided by the Flink runner, which you could pass as program arguements to enable checkpointing and to adjust the application’s retry behavior.

#	Option	Description
1	--checkpointingInterval	Checkpointing interval in milliseconds
2	--executionRetryDelay	Delay in milliseconds between retires
3	--numberOfExecutionRetries	You may use a larger value if you've coded your app to retry only for transient errors. So the pipeline could eventually recover itself once the underlying error go away

Differentiate Between Transient & Non-Transient Errors

An error could be identified as a transient or non-transient error based on the Java type of the exception being thrown. Unless the exception is known to be due to a transient error (an error that could eventually recover by retrying), that exception should be considered as a non-transient error.

class CustomDoFn<I, O> extends DoFn<I, O> {

    @ProcessElement
    public void processElement(ProcessContext c) throws Exception {
        try {
            process(c);

        } catch (Exception e) {
            handleException(e);
        }
    }

    protected void handleException(Exception e) throws Exception {
        Throwable cause = ExceptionUtil.getRootCause(e);

        if (cause instanceof TransientErrorException || ..)
            throw e;
    }

    protected abstract void process(DoFn<I, O>.ProcessContext c) throws Exception;

}

To eliminate the need to write exception handling logic in every user-defined DoFn, you may define a CustomDoFn class that your other DoFn classes could inherit from.

How Exceptions Propagate

The following diagram shows how exceptions propagate in Apache Beam. Since transient exceptions are not caught, those exceptions will cause Flink’s restart strategy to kick in.

Recovery and Retry Behavior

When a task failure happens, Flink restarts the failed task and other affected tasks. The last successful checkpoint is then used to recover the state including the corresponding stream positions.

Assume a scenario where the pipeline consumed four messages, M1, M2, M3, and M4. M1 and M2 were already sunk downstream. M3 and M4 are currently in processing.

When PubsubIO is being used as the source operator, message acknowledgment happens at the time of checkpoint finalization. So in the above example, only M1, and M2 are acknowledged. Say the pipeline fails to process M4 due to a transient error, this would cause related tasks to be restarted starting from the last successful checkpoint. So M3 and M4 will be replayed, starting from the source operator.

If the source operator is a KafkaIO for example, when the task restarts, the operator state will be recovered with properties such as the latest offset consumed so far, that are stored in the last successful checkpoint.

CVE-2021-44228 Fixing Log4J2 Vulnerability in Spring Boot

2021-12-11T07:30:00+00:00

How to check my application is vulnerable?

For your application to be vulnerable log4j-core has to be in your classpath.

The vulnerability is only present in log4j-core 2.14.1 and earlier versions.

For Maven projects:

./mvnw dependency:list | grep log4j

For Gradle:

./gradlew dependencies | grep log4j

Once you grep the console output, check whether log4j-core is present in your dependencies list. You can ignore log4j-to-slf4j and log4j-api dependencies in your grep output as these two were included by the spring-boot-starter-logging and cannot be exploited on their own. Only applications that include log4j-core and accept user input to format log messages are vulnerable.

Fixes

If your application is vulnerable consider one of the following fixes.

Upgrade log4j to 2.15.0 or newer
Remove org.apache.logging.log4j.core.lookupJndiLookup class from the classpath
Switch to SLF4J

Running SonarQube in ECS

2021-02-24T18:00:00+00:00

This guide briefs the steps required to deploy SonarQube Server in Amazon ECS. An ECS task definition needs to be created which is then used to launch SoanrQube as a service within Amazon ECS. Ready-made docker images for different SonarQube editions and versions can be found in Docker Hub, which we’ll be using for the deployment.

Create an EFS file system to be used with SonarQube When running SonarQube in ECS, persistent storage such as an EFS volume is required to prevent data loss. Otherwise, essential server data could be lost in case the container restarts or terminates. It also helps when updating the server to a new version or upgrading to a higher edition.

Create ECS task definition

Make sure that the task execution IAM role has full access to the EFS created.

Furthermore, this role should have the necessary permissions required to pull container images and to publish logs to Amazon CloudWatch.

Set an appropriate task size

As mentioned in the docs, SonarQube server requires at least 2GB of RAM to run efficiently and 1GB of free RAM for the OS.

Volumes

Under volumes add the EFS file system that is being created for SonarQube.

Container definitions

Under container definitions, specify a SonarQube image as the image used to start your container. If this is image is being stored in ECR, make sure that the ECR Task execution IAM role has the permission to pull images from ECR.

Port mappings

The default port that SonarQube runs is “9000”. So under port mappings also set the container port to 9000.

ENVIRONMENT

The default operating system limits on mmap counts are likely to be too low, which may result in out-of-memory exceptions. Therefore, SonarQube recommends that we set vm.max_map_count to a value greater than or equal to 524288. However, in ECS we can not control the ability to create memory maps.

So disallow memory-mapping altogether, enter the following Docker CMD parameters, into the input field named ‘Command’.

-Dsonar.search.javaAdditionalOpts=-Dnode.store.allow_mmap=false

Environment variables

The following environment variables should be set. These are referenced by the SonarQube docker image and is required to be able to successfully run the application.

SONAR_JDBC_URL
SONAR_JDBC_PASSWORD
SONAR_JDBC_USERNAME

If the JDBC URL is updated, the server ID, which is stored in the database will be re-generated and you’ll need a new license. So make sure to use an external database and to make backups.

STORAGE AND LOGGING

Under ‘STORAGE AND LOGGING’, add the following mount points to your EFS volume.

/opt/sonarqube/data
/opt/sonarqube/extensions
/opt/sonarqube/logs

RESOURCE LIMITS

The user running SonarQube should have permission to have at least 131072 open descriptors and should be able to open at least 8192 threads.

Set the recommended Ulimits under ‘RESOURCE LIMITS’

Limit name .	Soft limit .	Hard limit
NOFILE	131072	131072
NPROC	8192	8192

Creating the SonarQube Service

Now create a service from the task definition created. In the service configurations make sure to set FARGATE as the launch type. Set the ‘number of tasks’ to 1. Since, running multiple instances populating the same database is only supported by the Data Center Edition, and requires further configuration changes.

Make sure that the security group attached to the service instance has an inbound rule that allows TCP 9000. Also add an inbound rule of type NFS, for the instance to be able to access the EFS volume created. Once the task is up and running, the SonarQube server should be accessible via the private IP of the running task and port 9000.

Additionally, one could set up DNS routes, so to have convenient access to the server.

Traverse Fractured Space Time - Indie Game Review

2020-01-16T19:20:00+00:00

The following is a game review written by Wahaj, a tech enthusiast, writer, and aspiring physicist, about my first ever indie title, Gravity. Since this being a Linux blog, I’m also happy to announce that this game falls under the #MadeOnLinux category.

Gravity is a very recently released Android game from the indie developer Gayan Weerakutti. The developer has been working on the game part-time for over a year, making this something of a passion project. The game itself is a brain teaser style game with a Sci-Fi theme, and gameplay elements designed to match the theme.

Plot

The plot is fairly simple and straightforward and is only really explained at the beginning of the game. In its search for new resources and exploration, it has run out of resources and is in significant danger. Humanity is now relying on a single explorer to do whatever they can to guide humanity back to stability. The writing is pretty basic and there is a lot to be fleshed out, but the story only plays a small part in the game so it is not a huge bother.

Gameplay

The gameplay, like the plot, is fairly simple. However, this time, it plays into the game’s advantage, as it leads to a nice intuitive experience. This is how it works: you move your character across some tiles, and you need to avoid the black holes and reach the final destination. However, there’s a catch. On alternating turns, you can only move 1 tile and 3 tiles. This is supposed to represent the 4-dimensional structure of space-time being fractured. There are an additional element of power-ups that are unlocked as you progress in the game. The puzzles can be challenging and if you don’t think them through, some of them are really difficult. However, they are fun at the same time. As you move on, additional gameplay elements that make the puzzles a bit more complex, however, without losing the games inherent intuitive simpleness.

Visuals and Audio

The game incorporates soothing music, reminiscent of a lot of minimalist indie games and that’s certainly a nice thing and makes the experience a relaxing one, where you can just wind down. The same goes for the visuals, which are heavily Sci-Fi themed. Your character is an astronaut, walking across the background of space.

Conclusion

Overall, Gravity looks like a nice indie game that combines a lot of simple but fun gameplay elements, along with charming visuals and sounds. It even manages to have no forced ads that would distract you, despite being available for free on the Google Play Store.

SonarQube Pull Request Decoration

2019-11-24T05:30:18+00:00

Pull request decoration did not happen

If you got this warning I recommend that you first enable debug logs on your SonarQube server. Then perform a pull request analysis again while inspecting the ce.log.

tail --follow sonar-dir/logs/ce.log

If you see these warnings, most probably the system clock of your server is to blame.

GET response did not have expected HTTP code (was 401): {“message”:”‘Issued at’ claim (‘iat’) must be an Integer representing the time that the assertion was issued”,“documentation_url”:“https://developer.github.com/enterprise/2.18/v3”}

Pull request decoration did not happen. Please install SonarQube Github application on the repository’s organization or user.

To synchronize a system clock to real time, the most recommended solution is to install is chrony.

sudo apt install chrony
sudo systemctl restart chrony.service
sudo systemctl enable chrony.service

If using a RHEL based distro, run:

yum install chrony
systemctl start chronyd

To check whether there is an actual time drift, issue the following command

$ chronyc tracking
Reference ID    : A9FEA97B (169.254.169.123)
Stratum         : 4
Ref time (UTC)  : Sun Nov 24 15:45:37 2019
System time     : 46.211318970 seconds fast of NTP time
Last offset     : -0.000026256 seconds
RMS offset      : 0.002788091 seconds
Frequency       : 41.560 ppm fast
Residual freq   : -0.005 ppm
Skew            : 5.294 ppm
Root delay      : 0.000519169 seconds
Root dispersion : 0.000747741 seconds
Update interval : 71.3 seconds
Leap status     : Normal

As you could see from the output, my System time was drifted by about 46 seconds. If there is a time drift, chrony will automatically adjust the clock gradually. You can verify that by issuing $ chronyc tracking command and observing the System time line of the output. Once the ‘System time’ property is driven closer to zero, you could try re-running a PR analysis and PR decoration should work fine.

Socket time out

Increase javaOpts …

Install Unity3D on Linux

2019-01-06T17:02:23+00:00

I’ve been running Unity on my Debian / Ubuntu machines for so long and never have any issues whatsoever. As of now Ubuntu 18.04, and CentOS 7 are listed as the officially supported distros. I’m currently developing a sci-fi brain teaser which is currently on closed beta on Google Play, is solely build on Unity Linux. Again, it’s no different from running it on a Windows machine.

The preferred way of installing Unity on Linux is by first installing Unity Hub.

Install & Run Unity Hub on Linux

You can find the Unity Hub setup file in here:

https://public-cdn.cloud.unity3d.com/hub/prod/UnityHub.AppImage

You can also refer to Unity Hub sub-forum in forum.unity.com for additional information and to make sure that you’re downloading the latest available version.

Once downloaded, you may need to give execute permission to the UnityHubSetup.AppImage

cd /path/to/download/dir
sudo chmod +x UnityHub.AppImage

Then run the setup file. Either run it from the terminal or just open the file from a file manager.

Install Unity from Unity Hub

In the Installs section of Unity Hub application, you can choose a preferred version of Unity that you want to install. Unity Hub will automatically download and install it for you. One can have several Unity versions installed. Unity Hub allows you to easily switch between those different versions of Unity.

Unity recommends that we use Unity Hub for creating, opening, and managing all the projects. So always use Unity Hub instead of directly running a specific Editor version which usually gets installed under ~/Unity/Hub/Editor/[Version]. You may create a shortcut to your UnityHub.AppImage file for convenience.

Unity Crash

If your Unity crashes, most probably your graphics driver is to blame.

If you have an Intel graphic card that is 2007 or newer, try uninstalling xserver-xorg-video-intel. Your system will then default to use the builtin modesetting driver instead.

dpkg -l xserver-xorg-video-intel
sudo apt-get purge xserver-xorg-video-intel

If that still not fix your issue, try asking in the forums.

If it’s not a known issue, you could always send a bug report by opening an issue in Issue Tracker and Unity team probably will get back to you.

Recovering corrupted NTFS partitions in a Linux machine

2018-08-14T05:12:18+00:00

What if my partition is not showing up or gone missing?

In that case, TestDisk could help. It is a disk utility designed to help people recover their lost partitions.

To install it, here in my case on Debian, I’ll do

$ sudo apt-get install testdisk
$ testdisk

TestDisk has a QUICK SEARCH option which can search and list all your missing partitions if there’s any. Most probably your missing partitions should have appeared by now. If not, try running a DEEPER SEARCH. Once it found any, use the WRITE option of TestDisk which will re-write the partition table for you.

Restart your computer and your missing partitions should now show up.

I won’t go into detail. For a more thorough guide, follow the Step By Step guide from the official Wiki.

How to fix when my NTFS goes RAW?

It’s better to use Windows utilities when it comes to dealing with NTFS.

Boot into a Windows Recovery Disk.
Then go into ‘System Recovery Options’ menu.
Open the command prompt window.
Use one or more of the following commands to find out the label of your corrupted partition.
```
 diskpart list disk
 diskpart select disk
 diskpart list volumes
```

Once done exit from diskpart and run

 chkdsk /f /r D:
 where D: is the drive letter of the corrupted partition. 

If you have got better solutions, let us know in the comment section.

Fixing JHBuild Errors

2018-08-14T05:12:18+00:00

Fixing no native package found errors

JHBuild uses apt-file to locate packages in which a given file belongs to.

When apt-file cannot locate the relevant packages for you, JHBuild would give you with informational warnings such as:

I: Installing dependencies on system: libsystemd-journal libtiff
I: Using apt-file to search for providers; this may be slow. Please wait.
I: No native package found for libsystemd-journal (/libsystemd-journal.pc)
I: No native package found for libtiff (/usr/include/tiff.h)

In such cases, first make sure that your apt-file database is up-to-date.

sudo apt-file update

Then re-run the process. JHBuild might still fails to complete the process. This could be due to several reasons. So for instance if apt-file finds several packages which includes the same file, JHBuild would fail to decide on which package to install. In that case we’d have to find the most appropriate pacakge and install it manaully. Also the actual package name can be sligtly different from the name stated in the warning.

To find the relevant package which includes the given file, you could run:

apt-file search path/to/missing.file

You could also use Ubuntu’s package archive search on web, instead of apt-file. But apt-file usually is more convenient.

Go to packages.ubuntu.com
Search the contents of packages which include the missing file.
Find the relevant package for your distribution and install it.

For example here the missing libsystemd.pc belongs to the package named ‘libsystemd-dev’

Therefore running apt-get install libsystemd-dev should fix it.

Fixing No matching system package installed

This type of errors can be quite tricky as your distribution might not have a package that is newer than the required version.

Example cases:

libsystemd-journal (libsystemd-journal.pc, required=201)

Ubuntu’s Launchpad provides compatibility package for libsystemd-journal-dev (>201) which includes the required .pc file. Downloading and installing latest binary .deb file for your distribution should fix it.

Fixing configure errors: Package requirements (package-name) were not met

In that case do,

apt-cache search package-name

This will list down all the packages for the given keyword: package-name

Find the required development package from the list and install it. On a Debian based system the package name would probably contain a *-dev suffix. For Fedora, look for ‘-devel’

For example to fix “configure: error: Package requirements (libselinux >= 2.0) were not met”

Run the following in a terminal

apt-cache search libselinux

On my system the output is,

libselinux1 - SELinux runtime shared libraries
libselinux1-dev - SELinux development headers
libsemanage1 - SELinux policy management library

So installing ‘libselinux1-dev’ should fix the configure error.

apt-get install libselinux1-dev

Install Windows after Ubuntu/Linux

2017-10-11T05:30:18+00:00

As you know, the most common, and probably the most recommended way of dual booting Ubuntu and Windows is to install Windows first and then Ubuntu. But what if you want to install Windows second on a computer with Ubuntu/Linux already installed?

This guide assumes that you have Ubuntu already installed on your system, and will guide you through installing Windows 7/8/8.1/10 when you have a working Ubuntu/Linux partition.

The problem here is that the Windows installer tends to overwrite Grub bootloader or whatever making only the Windows installation bootable. But the good news is that your Linux partition is untouched, including the original bootloader and the other Grub configurations. So restoring or recovering Grub is just a matter of running a few commands on the terminal.

Install Windows on a Separate Partition

If your Ubuntu installation occupies the entire hard drive, to be able to create free space for the Windows installation, you may have to shrink an existing partition using a disk utility like GParted. GParted comes preinstalled on Ubuntu LiveCD.

Boot into a Windows installation media and complete the installation

Once installed, because of Microsoft’s false assumption that there are no non-Microsoft operating systems you’ll be taken straight into Windows.

Restore / Reinstall Grub 2 with a Ubuntu Live Media

Now boot into a Ubuntu Live/USB or CD.
Open a terminal. (Ctrl + Alt + t)
Use a command like lsblk, blkid or GParted to identify your Linux root, and boot partitions. You may or may not have a separate boot partition.

Find Linux Partitions

 $ lsblk -f
 NAME                  FSTYPE     MOUNTPOINT
 sda                                                                            
 ├─sda1                ext4       /boot
 ├─sda2                ext4       /
 ├─sda3                ntfs       

In my case,

/dev/sda1 is the Linux boot partition

/dev/sda2 is the Linux root partition

/dev/sda3 is the Windows partition

Setup a Chroot Environment

Now we’ll be repairing our old grub bootloader in a chroot environment.

Mount your root filesystem under /mnt
```
 sudo mount /dev/sda2 /mnt/
```
If you’re using BTRFS (New Linux B-Tree File System) instead of EXT4, the above command should change to sudo mount -t btrfs -o subvol=@ /dev/sda2 /mnt/

Run ls /mnt to verify that the correct partition is mounted. It should list the content of your root.
```
 $ ls /mnt
 bin   dev  home        lib64       media  opt   root  sbin  sys  usr  vmlinuz
 boot  etc  initrd.img  lost+found  mnt    proc  run   srv   tmp  var  vmlinuz.old
```
Mount the boot partition. (SKIP if you don’t have a separate boot partition)
```
 sudo mount /dev/sda1 /mnt/boot
```
If you have an EFI partition you should mount that also. It is basically a small FAT32 partition around 100mb. Please refer to the section on how to reinstall Grub in an EFI system.

Bind these directories, so grub can detect other operating systems, like so.
```
 sudo mount --bind /dev /mnt/dev
 sudo mount --bind /dev/pts /mnt/dev/pts
 sudo mount --bind /proc /mnt/proc
 sudo mount --bind /sys /mnt/sys
```
Let’s chroot into our existing Ubuntu/Linux system on the hard disk.
```
 sudo chroot /mnt
```
Reinstall Grub.
```
 grub-install /dev/sda (specify the disk `/dev/sdX`, not `/dev/sdaX`)
 grub-install --recheck /dev/sda
 exit
```
Once you’ve successfully reinstalled Grub, restart the computer. On next reboot Grub will be the default bootloader and you’ll be presented with a list of operating systems to choose from (Ubuntu and Windows, of course).

Reinstalling Grub in an EFI Based System

Reinstalling Grub bootloader in a UEFI based computer is no different from installing Grub on a legacy BIOS system. Here we also mount the EFI partition before chrooting, as we’d do with the boot partition.

Case #2

$ lsblk -f
NAME                  FSTYPE     MOUNTPOINT
sda                                                                            
├─sda1                ext4       /boot/efi
├─sda2                ext4       /
├─sda3                ntfs       

Here /dev/sda1 is the EFI partition and /dev/sda2 is the root.

sudo mount /dev/sda2 /mnt/

Mount EFI partition under ‘/mnt/boot/efi’

sudo mount /dev/sda1 /mnt/boot/efi

Forgetting to do so will result in errors being thrown while trying to execute grub-install: “/boot/efi does not appear to be the EFI partition”

As shown previously, bind the /dev, /dev/pts, /proc, and /sys directories.

Finally,

sudo chroot /mnt
grub-install
exit

In some rare occasions, Grub might not detect Windows. In that case just login to Ubuntu (installed one on the disk, not the bootable Live USB/CD) and execute,

sudo os-prober
sudo update-grub
sudo reboot

Happy Dual-Booting!