H2: Update titles

exercises/h2.md

@@ -108,7 +108,7 @@ If you buy very modern or customized hardware, please consider using a distribut
 
 A good friend of mine contacted me recently. He stated that he couldn't log in to his [Gentoo](https://en.wikipedia.org/wiki/Gentoo_Linux) installation. After a short talk on phone and various approaches I figured out that the problem must be on his LightDM manager so I adviced him to check his `/var/log/lightdm/` log files. It was proven that the problem was caused by faulty installation of LightDM package files (wrong permissions) or authentication errors oin his [PAM policy](https://en.wikipedia.org/wiki/Privileged_identity_management). To conclude, all these errors can be very random and results of various reasons, mostly due to hardware changes or system updates representing new bugs or conflicting configuration settings.
 
-#### Other error situations - a tricky error tracked down
+#### Other error situations - a tricky error tracked down (journalctl)
 
 Sample of [journalctl](https://www.loggly.com/ultimate-guide/using-journalctl):
 
@@ -154,7 +154,9 @@ The following journalctl snapshot tells that there is an issue with the bluetoot
 
 Bluetooth error messages: lines 7-19. Line 8 is not an error message.
 
-**Analysis - regression test approach:**
+**Analysis - regression test approach (journalctl)**
+
+The following analysis is a part of [the above journalctl issue]((https://github.com/Fincer/linux_server_setup/blob/master/exercises/h2.md#other-error-situations---a-tricky-error-tracked-down))
 
 The problem seem to be widely known among Ubuntu & Arch Linux users, according to a short search in the internet. There is a [launchpad report](https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1490349) but not a simple answer is given there. There is a suggestion to downgrade bluez package on [Arch Linux forum](https://bbs.archlinux.org/viewtopic.php?id=195886). [AskUbuntu](https://askubuntu.com/) website has many threads for this issue.
 
@@ -166,7 +168,9 @@ Basic principle of a regression test is to compile suspected packages from sourc
 
 Once the problematic commit/commits are known, we can fix the code ourselves and, for projects where the code is available to use, we can make a [pull request](https://help.github.com/articles/about-pull-requests/) which is accepted by verified developer, or in some cases, we can make our own [fork repository](https://confluence.atlassian.com/bitbucket/forking-a-repository-221449527.html) of the package/component/program. Therefore, commiting [a patch](https://www.thegeekstuff.com/2014/12/patch-command-examples/) or patchset to source code is possible.
 
-#### journalctl analysis - our bluez package
+**Analysis - our bluez package (journalctl)**
+
+The following analysis is a part of [the above journalctl issue]((https://github.com/Fincer/linux_server_setup/blob/master/exercises/h2.md#other-error-situations---a-tricky-error-tracked-down))
 
 In bluez error case, we should check all relevant error messages written by bluetooth daemon to STDERR output. By analysing [BlueZ source code](https://github.com/pauloborges/bluez) ([alternative link](https://git.kernel.org/pub/scm/bluetooth/bluez.git)) we can see that the message present in journalctl log snapshot can be found in source code as well. In more detail, the following source code files (C code):