Mounting Linux volumes with systemd vs fstab

sample fstab file in vimIf you have ever done anything more than just an out of the box linux installation you have more than likely worked with fstab to get your volumes to mount.  The screenshot to the left shows and example of an fstab file.  In this example we are going to look at /dev/sda6 which is mounted to /apps using the XFS file partition and using the defaults.  In the sample fstab file you will also notice other volumes mounted using UUID and also the volume label.  The UUID you can get by running blkid at the command prompt.  Both the UUID and label methods are best as things can change in the system that would change the /dev/sda6 name at which point you’ll have issues with your mounts.

I know that Red Hat is going to be using the systemd method of mounting in future versions of Red Hat, so it would be good to understand this way of doing it.  In all it is not that much more difficult to setup as before, however the mounts will all be controlled via the systemd process and you can use commands such as systemctl status, start, enable, and disable on your individual mounts.

The first step is to get a sample .mount file that you can edit for your purposes.  These files are located on your system at /lib/systemd/system.  When you are in this path you can do a ls *mount to get a listing of all the various .mount files available.  A good  one to choose is the tmp.mount file.  We need to copy this file to /etc/systemd/system/.

You want to pick a name that will be descriptive of what you are mounting.  In this example we are mounting an apps volume, so that is why I chose the apps.mount filename.

systemd mount file

We can then use vim to edit the file and change it to meet our requirements.   We can remove any information related to the tmp.mount file, and add the proper information to have our apps volume mount.  In the screenshot to the right you see an example of what the file should look like.  Under the [Mount] section we can enter the following:

  • what=UUID=”277927f6-a97a-4580-b409-eb9b6cb09fca”
  • where=/apps
  • type=xfs
  • options=defaults

As you can see the format is similar to what you have done in the fstab before.  Once you have this done you can save your file, and then it all comes down to standard systemctl commands.  Instead of all being on one line you enter them on four separate lines.  Also the use of UUID=”277927f6-a97a-4580-b409-eb9b6cb09fca” instead of /dev/sda6 is preferred to prevent issues if the device names change due to a file system reconfiguration later on.  Remember, you can see what the UUID of any device is by running the blkid command.

systemctl commands for mounting with systemd

Don’t forget to add the .mount at the end, as if you forget systemctl will think you are talking about a service and the command will fail.  Also be sure as with fstab and any other manual mounting method you have the mount point created, in our chase /apps.

At this point the volume will mount each time the system starts via systemd.  You’ll be able to remove this entry from your fstab file.

I hope you found this article informative.  If you have any questions, feel free to reach out to me.


Ivan Windon

How to reset an unknown root password on RHEL/CentOS 7.x

There may come a time in your day to day activities where you need access to a RHEL/CentOS server or workstation and you do not have the root password.  How do you go about changing a password, when you need root access to change passwords.  Fortunately there is a method which is fairly easy that allows you to reset the root password.  You do need physical access to the server however, so this can not be done via SSH or any other remote method.

Reset unknown root password adding rd.break to grub2 menuWe first need to reboot the server so we can get to the grub2 boot menu.  Once the menu is up just press the ‘E‘ key (for edit).  This will bring up all the boot options for you.  Move the cursor down to the end of the line starting with linux16.  At the end of the line you will want to type in rd.break.  This will break you into the boot process very early on and allow you to perform the following tasks.


Once you are at the prompt you will want to enter the following commands:

Reset unknown root password with mount, chroot, passwd, and selinuxTo explain the previous steps further, the mount command is to get our root partition in a Read / Write condition.  Without doing this we won’t be able to write to the /etc/shadow file and update our root password.

The chroot command changes our root path from /sysroot to /, this enables /etc/shadow to be in the correct path, instead of /sysroot/etc/shadow.  Without doing this the passwd command will not work properly.

Now we can issue the standard passwd command and change the password for root.

Our next steps deal with SELinux.  The context of the shadow file will be wrong as SELinux has not been loaded yet by using rd.break.  So we have to let SELinux know we made this change and configure it properly.  There are two ways of actually doing this.  You can create an empty file on the root with touch /.autorelable.  After the reboot SELinux will see this hidden file in the root partition and proceed to relabel every file on the system.  Depending on how large your system is and how many files there are, this could take some time.  A quicker method would be to just relabel the file we changed.  This is where load_policy -i and chcon -t shadow_t /etc/shadow come into play.

Finally we enter Control D twice.  The first to exit from our chroot, and the second to exit from the rd.break and continue the boot process.  At which point we can then login to the system with our new root password and gain access to  the system we previously did not have access to.

If you have any questions or comments, please feel free to reach out.


Ivan Windon


Changing grub2 boot options on UEFI boot system

On my workstation at home I have a dual boot with Red Hat Enterprise Linux 7.3 Workstation and Windows 10.  My system boots with UEFI which makes setting up dual boots such as this fairly easy.  I did want to make some changes to the default grub2 menu when my computer boots however.  First while I enjoy working with RHEL, my wife does not, so having the system boot into RHEL by default was causing some unneeded friction.  I also wanted to increase the default timeout, and remove RHGB quite from the boot menu as I like to see what is going on during the boot process.  So I set out to make the needed changes.  You’ll need to be root to perform all the following tasks.  First off, you don’t just edit the grub.cfg file directly, as this file is automatically generated, and if you issue the command cat /boot/efi/EFI/redhat/grub.cfg | less it will tell you as much at the start of the file:

# It is automatically generated by grub2-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub

Okay, easy enough.  So we use vim to edit /etc/default/grub

GRUB_DISTRIBUTOR=”$(sed ‘s, release .*$,,g’ /etc/system-release)”
GRUB_DEFAULT=”Windows Boot Manager (on /dev/sdc2)”

The above file is after I had made all my changes.  I changed GRUB_TIMEOUT to equal 15, changed the GRUB_DEFAULT to read “Windows Boot Manager (on /dev/sdc2), and removed RHGB quite from after on the GRUB_CMDLINE_LINUX line.  For the exact wording of the default just look at the grub boot menu when your system is booting up and it write down which OS or option you wish.  By default it reads GRUB_DEFAULT=saved, and this would always give me the first option as my default.  I wanted the last option to always be my default, so I changed it to read my Windows Boot Manager instead.

Now while editing this file be VERY CAREFUL not to make any typos as it can cause your system to not boot properly.  I (which I’m still not sure how it happened) accidently ended up changing to  Like I said, I’m not sure how it happened and I didn’t notice it and after I wrote the file and rebooted my system would no longer boot.  Instead I was greeted with hundreds of dracut-initqueue[345]: Warning: dracut-initqueue timeout – starting timeout scripts.  I was very confused at first why it would do this.  I tried a few other things like trying to boot to an older kernel, none of them worked.  I tried breaking into the boot and adding to the boot parameters, however seeing the issue was the root volume wasn’t being mounted none of these options would have ever worked.  I knew it had to be something I had just done, as the system worked just seconds ago, but for the life of me I couldn’t see why removing RHGB quite would have any negative effect.  It wasn’t until I was staring at the boot parameters I noticed the dd instead of the rd.  I was then able to edit the grub file again, and write my changes to grub.cfg.

So our final step in this process is how do you get your changes you made in /etc/default/grub to /boot/efi/EFI/redhat/grub.cfg.

[root@rhelws redhat]# grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg

Running the grub2-mkconfig file with -o (for output) and telling it where to create the file, which for a UEFI system would be something like /boot/efi/EFI/redhat/grub.cfg.  If you don’t see yours there one way I found to find it is to look in the /boot/grub2 folder and do a ll command:

[root@rhelws grub2]# ll
total 8
-rw-r–r–. 1 root root 4710 Apr 11 13:09 grub.conf
lrwxrwxrwx. 1 root root   28 Apr 11 15:11 grubenv -> /boot/efi/EFI/redhat/grubenv
drwxr-xr-x. 3 root root   19 May  9  2012 themes
[root@rhelws grub2]#

Notice the hard link with the file grubenv which is pointing to /boot/efi/EFI/redhat/grubenv.  This would be a good bet of where your grub.cfg file should go.  Once you are done you can do a cat grub.cfg | less to view the newly created file and verify all is right before issuing the reboot.  When you are happy, just issue the systemctl reboot command and you’ll see the results of your changes upon bootup.

I hope you have found this short tutorial (and tale of caution) informative and helpful.  If you have any questions, feel free to ask, and be sure and visit again soon for my posts on RHEL 7.x


Ivan Windon

Red Hat Summit 2017

Red Hat Summit 2017 will be in Boston this year, and I will be going for the first time.  I am looking forward to this conference and working in some of the labs.  The conference itself is three days long in the first week of May.  With my heavy interest in security and networking many of the sessions I am attending are focused around the security track offered by Red Hat.  Below is my current schedule for the week.


  • 10:15 – 11:00 – S102106 – Red Hat Security Roadmap
  • 11:30 – 12:15 – B104934 – The age of uncertainty: how can we make security better
  • 3:30 – 5:30 – L103745 – Hands on with the pros and the latest Red Hat Enterprise Linux capabilities


  • 10:15 – 11:00 – S105084 – Security-Enhanced Linux for mere mortals
  • 11:30 – 12:15 – S104249 – Identity and access management: Choosing the right tool for the right job
  • 3:30 – 4:15 – LT122001 – Lighting Talks: Infrastructure security
  • 4:30 – 5:15 – S105099 – High-availability clustering in Red Hat Enterprise Linux


  • 10:15 – 12:15 – L100049 – Practical SELinux: Writing custom application policy
  • 3:30 – 4:15 – B102584 – Red Hat Satellite – B0F

It will also be interesting to see how the Red Hat Summit compares with previous conferences such as Cisco Live and RSA.  Both conferences were longer and the schedules were fuller each day.  Based on the scheduling I see so far there is a large amount of hours open during the middle of the day.  I plan on using this time for eating, reviewing notes, meeting up with people, and visiting vendors of interest on site.  In any case I should have some great information to bring back and write various articles for this site.  Be sure and visit again for follow up posts on this subject.

Using Subscription-Manager and YUM in RHEL for new systems with a proxy

After installing RHEL the first steps that you will want to accomplish is registering your system with Red Hat, attaching your system to the appropriate subscription, and running YUM update to bring your system up to date.  If this is within a corporate network many times you’ll run into the problems of not being able to connect to the Red Hat network until you make some configuration changes both within Subscription Manager, and YUM.

The steps required to get this setup are fairly easy, however if you’ve never had to do it before might be difficult to locate.

First in order to register the system with Red Hat you’ll want to run the subscription-manger config command to set your company proxy, and port number.  You’ll want to use the command:

You can then register your system with the command:

If you leave off the username and password options you will just be prompted to answer these connections the first time you are connecting before registration completes.

Next we can attach our system to the appropriate subscription.  We first need to view what subscriptions we have available:


Available Subscriptions

Look through the various subscriptions you have and make note of the pool ID for the one that matches your system.  If all your subscriptions are the same you can use the auto option, however many companies have a variety of subscriptions so you’ll want to have control over which one you connect to.  Run the following command to attach to the required pool:


Once this has completed you are now ready to update your system with YUM.  However you’ll need to adjust the configuration of /etc/yum.conf and add the line to the last line in the configuration so that YUM will work via your company proxy.

This can be done with VIM by typing the command:



Edit the file, and then save the configuration.




You can then run your first update on the system to bring everything up to date with the command:

I like running it without the -y option so I can see what is all going to be installed and have the option of choosing no if needed for any reason.  However if you don’t want to have to do this, just add -y to the command and all the updates will be installed and updated automatically.

And that’s pretty much it.  There are other configuration options in subscription-manager, such as telling it to stay on a current version of RHEL.  For instance if for some reason you need to always be at 7.2 and don’t want to upgrade to 7.3 or any other versions later on you can set your release with the command:

There are other options you can view by double tabbing either after the subscription-manager command, or after you have typed in an option such as config, release, list, etc.  That will show you all the — options that are available to you as well.

subscription-manager options




Hopefully you have found this short tutorial helpful.  Feel free to ask me any questions you may have.