Zen Installer: Installing Arch Linux and the Subsequently Confusing FSCK Issue

So, I recently installed Arch Linux (via the Zen Installer) and all went well. Well, until I removed the USB the OS was installed from and rebooted, that is…

systemd_fsck_dependency_failure

Plug the USB stick back in and the system would boot normally. Checked FSTAB and it looked entirely valid and was, since the system was in running state when I did.

Markering_001

O.k., let’s try this again but this time check the journal (journalctl -xb) to see what’s happening.

jul 14 21:37:42 [REDACTED] systemd[1]: Starting File System Check on /dev/sdb1…
jul 14 21:37:42 [REDACTED] systemd-fsck[463]: /dev/sdb1: 17 files, 12139/130807 clusters
jul 14 21:37:42 [REDACTED] systemd[1]: Started File System Check on /dev/sdb1.
jul 14 21:37:42 [REDACTED] audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg=’[email protected] comm=”systemd” exe=”/usr/lib/systemd/systemd” hostname=? addr=? terminal=? res=success’
jul 14 21:37:42 [REDACTED] kernel: audit: type=1130 audit(1563133062.173:11): pid=1 uid=0 auid=4294967295 ses=4294967295 msg=’[email protected] comm=”systemd” exe=”/usr/lib/systemd/systemd” hostname=? addr=? terminal=? res=success’
jul 14 22:19:49 [REDACTED] systemd[1]: [email protected]: Succeeded.
jul 14 22:19:49 [REDACTED] systemd[1]: Stopped File System Check on /dev/sdb1.
jul 14 22:19:49 [REDACTED] audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg=’[email protected] comm=”systemd” exe=”/usr/lib/systemd/systemd” hostname=? addr=? terminal=? res=success’
jul 14 22:19:49 [REDACTED] kernel: audit: type=1131 audit(1563135589.643:55): pid=1 uid=0 auid=4294967295 ses=4294967295 msg=’[email protected] comm=”systemd” exe=”/usr/lib/systemd/systemd” hostname=? addr=? terminal=? res=success’
jul 14 22:21:44 [REDACTED] systemd[1]: dev-sdb1.device: Job dev-sdb1.device/start timed out.
jul 14 22:21:44 [REDACTED] systemd[1]: Timed out waiting for device /dev/sdb1.
jul 14 22:21:44 [REDACTED] systemd[1]: Dependency failed for File System Check on /dev/sdb1.
jul 14 22:21:44 [REDACTED] systemd[1]: [email protected]: Job [email protected]/start failed with result ‘dependency’.
jul 14 22:21:44 [REDACTED] systemd[1]: dev-sdb1.device: Job dev-sdb1.device/start failed with result ‘timeout’.

Well, that didn’t help too much, save to tell me that fsck can’t load a dependency. Wait a minute… It can’t be… Can it?

Ctrl+Alt+F1 to open the terminal. Nano’ed fstab. Changed all of the sdb to sda (since the usb was no longer plugged in) and rebooted. It worked.

So, here’s what was happening:

When the USB drive was plugged in, the HDD drive was /dev/sdb. When the USB was not plugged in, it was no longer /dev/sda but the HDD was now /dev/sda.

The ultimate work-around to prevent this from happening again? Use the UUIDs instead of the non-static drive assignments, as the kernel’s name descriptors are not persistent. (See the Arch Linux Wiki for more details.)

Obligatory desktop screenshot? Obligatory desktop screenshot.

Markering_004

 

 

C#: Returning ADSI COM Properties of a User Object (Or Any Object, Really)

NOTE: This post – drafted, composed, written, and published by me – originally appeared on https://blogs.technet.microsoft.com/johnbai and is potentially (c) Microsoft.

A few months ago, I was working on a project to query for specific AD properties of a user-object programmatically. I knew the properties I wanted to return and I had worked with returning properties in ExBPA/HRC. I hadn’t, however, found the joys of receiving a System.__COM object in any of my returns until now.

To explain this, you should familiarize yourself with ADSI (Active Directory Service Interfaces), if you’ve never been exposed to it, before. As the previous link points out, ADSI is a COM (Component Object Model), and – as such – we will get a return of ‘System.__COM’, if we fail to pull the data in the expected format.

So, how was I to return the data from the COM? Well, as it turns out, there’s ‘deprecated’ documentation which helped me farther than any blog, technical bulletin, or reference did. You can find it, here. (Apologies, apparently all of the English versions have been pulled because it was deprecated.)

Using some ingenuity and a little luck, I found the answer to my problem: return the value I’m querying for as ‘ActiveDs.IADsLargeInteger’.

So, armed with this knowledge, I could now pull the properties I wanted to return in usable context, like the following:

ActiveDs.IADsLargeInteger recipientTypeDetails = (ActiveDs.IADsLargeInteger)userResult.Properties[“msExchRecipientTypeDetails”].Value as ActiveDs.IADsLargeInteger;

Once I had the data ‘out’, as it were, I could try to manipulate it:

long recipTypeDetails = recipientTypeDetails.LowPart;

 

I realize this doesn’t mean much to some people (maybe a lot) but I figured if I could save one person the hours it took me to find the answer, then it was well worth the time in writing this.

Happy coding!