Update to Post: Setting Up an Operating System with a Home Directory on a Separate Disk

In my last post, which was a while ago, I went over how I installed Peppermint OS onto my Acer Aspire laptop. On that article, I had some instructions on how to do it that I need to update.

The issue was, whenever I edited the /etc/fstab file and mounted it with the old home files on that disk by rebooting, the new distro’s desktop would be replaced with the last instance of the desktop look, feel, and panel/dock that I had on the previous install of that desktop environment’s config files. But I figured our a way that is more efficient than what I presented the last time. Here are the main changes that I have to offer to what I wrote in How I Installed Peppermint OS PCNetSpec Edition onto a Computer with a Separate Disk as the Home Directory

You should do these steps before you update and upgrade the system. One of the first things you should do is to edit the fstab file in the /etc directory, before much changes happen to your current home directory after an install. It doesn’t matter whether you do these steps before or after you edit the fstab file and set it to use your drive for a home directory. If you do edit the fstab file before you do this, just make sure you don’t reboot until you’ve done the following steps:

After mounting the old disk on /mount/rick/myhome as instructed in the second set of steps, look for point #4 of the above referenced article, go to the config directory where your desktop files are configured. This is normally at ~/.config/(desktop directory). If you are doing this on a peppermint install, that would be the XFCE DE. But I believe these steps would work for most DEs, However, I’ve only tested this on XFCE thus far. Note, I will use my own disk’s label and directory below. Make sure you use your own directory for your setup. Enter:

cd /media/$USER/myhome/$USER/.config

cp -r ~/.config/* ./ This will effectively copy all config files over to your disk myhome mount.

With that steps done, you are now ready to reboot into your system, assuming you have already edited the fstab file to mount the new disk to /home. Otherwise, you’ll need to edit and add the disk info as detailed in the above article to switch your home directory to the disk it is on. Then you will be ready to sudo reboot!

That’s all you have to do to save the settings on a newly installed distro with an XFCE desktop environment.

Also, in my original article, I have some instructions on how to access the blkid app when it isn’t in the path of the user, by adding that path to the users current path variable, which you can check by entering echo $PATH into a terminal.You will be looking for the /usr/sbin directory, specifically, that is where the program resides.

Or, you may wish to not add that directory path to the $Path variable. You can still run the program by adding “sudo” to the beginning of the command, like this:

sudo blkid

Enter your password in and then it will run the app and you can do the same to reboot the computer from the command line in a terminal--sudo reboot or you can use the DE’s logout function.

If you did not run any of the programs on your new system, the files you copy from your “new” home directory will be the settings for the current desktop environment to your “old” home directory. will overwrite past settings for the specific distro onto your soon-to-be home directory, thus preserving the distro’s settings. If you wish to save certain settings from your old home directory, I would suggest copying the whole .config directory to a backup directory:

mkdir ~/.old-config && cp -r ~/.config/* ~/.old-config

You can, of course, use whatever naming scheme you wish for the backup directory.

Then proceed with the home directory instructions and your own tweaks to the system.

How I Installed Peppermint OS PCNetSpec Edition onto a Computer with a Separate Disk as the Home Directory

. . . and kept the original Peppermint settings once I linked my home drive on the alternate disk.

Yep, that's the setup I have on my Acer Aspire 5 thin laptop (using a AMD Ryzen 3 cpu and a AMD Radeon GPU). I have a 119 GB nvme drive, and an alternate SSD drive of 1 TB. I bought that drive once I realized my computer had a spot for it when i was installing more memory in it. It was then that I had the "brilliant" idea of using that spot for my home directory, especially since I was afraid that the nvme card wouldn't be big enough to hold my whole home directory plus system files. So I ordered and installed the drive. I followed some directions on the Internet on how to move my home directory to a separate hard drive. I successfully had a system that gave me plenty of room to expand on both the system (119 GB) and on my home directory (1 TB). Plus, I have a 2 TB external drive which connects via USB for doing my backups.

Now, I had, at the time--after a period of distro hopping (that is a term for anyone who regularly installs new Linux, or other kernel/systems such as BSD, on their computer because of various reasons), looking for a distribution that would work best for me--installed Neptune OS, which uses the KDE Plasma desktop environment (DE). I used that distro for around one year before I decided to distro hop again. If I recall correctly, the first distro hopping I did on this laptop, was in the following progression: Peppermint OS (had a problem updating), Sparky Linux (couldn't get it to install correctly), Garuda Linux (it broke down on an upgrade), Linux Mint Debian Edition (mostly as I needed a stable system and I knew it would work) and a few others I don't recall right now. Somewhere in that first distro hopping period, is when I started using that extra 1 TB drive.

There are several posiitives to doing it this way, but the biggest one is: All of your user settings for the various programs you use are retained upon installing a new distro. For example, upon reconnecting my home directory to the new computer system and opening up my fresh install of Brave or Firefox browser, all of my settings and bookmarks are just as I left them. I was even still logged into my Google account!

Likewise, the main downside is that all of my user settings were retained. Which was a negative when after installing a new distro with, for example the XFCE DE, I would set up the DE like I would want it. But when I connected my home drive to it, all my settings would revert to a previous distro's XFCE's configuration. That actually happened when I first installed Peppermint OS on the Acer, as soon as I connected with my home directory, the panels, theming, wallpapers, all switched over to a previous install of an XFCE DE I had when I ran for a time OpenSUSE, with all its keybindings (the good thing) and all of its inherent problems like the settings for the display not sticking, that is, not being saved and reloaded on a reboot/restart of the session (definitely not a good thing).

So, when it came time to do a fresh install of Peppermint on the system, I decided I wanted to try something I'd not done before. My usual process after installing and updating the system and programs was to reconnect my home drive to the install. "How?"

1) Open a terminal bash session and type:

lsblk

. . . to identify the device location of the home drive. Helps ensure that I've got the correct drive.

2) I then run the following command:

blkid

This will give you a list of the drives and partitions on your disks, but the key part you are looking for is the partition where your home directory is residing. You should be able to see the UUID sequence of letters and numbers in groups of four. It will look something like: xxxx-xxxx-xxxx-xxxx-xxxx. You'll want to mark and copy just the number/letter combination using your mouse to mark the text and holding down the Ctrl and Shift keys at the same time, then pressing and releasing the "C" key. That key combination is usually represented as Ctrl+Shift+C.

If you are on a Debian-based distro, or Debian itself, you may not be able to find the command on your computer. While it is often there in /usr/sbin, it is only that the command's path isn't in the user's path environment variable. To correct that, type in the following command into the terminal:

export PATH="/usr/sbin:$PATH"

It will only last until you close the terminal. To make it a last beyond that terminal session, enter the same command in the .bashrc file, or one it includes. Now, if the program is there, it should show up.

3) Now, I edit the fstab file in the /etc/ directory using your favorite text editor--I tend to use nano since it is on most systems. The purpose of the fstab file is that it will tell your operating system where to mount and find your system, boot files, as well as any other directories such as the one that we just created in our example above.

sudo nano /etc/fstab

4) Then I make an entry for attaching my home directory upon bootup:

I enter "UUID=" then I paste the number/letter that I copied in step 2 above by again holding down the Ctrl and Shift buttons, but this time pressing and releasing the "V" key. Press the spacebar or the tab key, then enter "/home" which will tell the system where to mount the drive. After another space or tab, you'll enter the filesystem it uses, which in most cases will be ext4. Then you'll enter some flags or commands that tell what the drive will do. So after another space or tab, enter "default,noatime", followed by a "0" and a space, then a final 0. By the time you're finished, you should have something that looks like the following, with, of course, your specific UUID code in place of the x's:

UUID=xxxx-xxxx-xxxx-xxxx-xxxx /home ext4 default,noatime 0 0

You'll notice that the pattern matches that of the other drive as well. Once entered, save the file by pressing and holding the Ctrl key, then press the "S" key. Now you are ready to exit the file by once again holding down the Ctrl key while pressing the "X" key.

5) Then, to activate the switch to the new home directory, you'll need to reboot. Once you've done that, you should have access in your home directory to all the files you had on the disk before. The advantage of this is big, in that while I would recommend backing up your home directory, just in case you over write it with your new system you're installing, there is no need to restore your home directory's files from a backed up copy. Plus, as I've already mentioned earlier, you'll automatically have all your user settings for your programs. So, if for instance, if you use Thunderbird as your email client, you won't have to reset up your email accounts again. It's as if you never switched systems.

So what did I do differently to fix my other problem?

1) Certainly before step # 5, but you can do this at any point after you install and update a new system, I'll first create a temp mount point for the old home directory.

For Debian and systems based on it, you'll enter:

cd /media

For Arch and most other systems save a few, you'll add a "/run" directory so that you'll enter:

cd /run/media

2) Then you'll need to create a directory for your user

sudo mkdir $USER

In my case, it would create the directory "rick" so it would read /media/rick

3 ) However, you'll need to change the ownership of the user's directory to the user, so you would enter:

sudo chown $USER:$USER $USER

4) Then you would create the mount point directory inside the user's directory:

cd $USER && mkdir /myhome

5) Then we would mount the directory:

sudo mount /dev/sda1 /media/$USER/myhome

or on non-debian-based systems:

sudo mount /dev/sda1 /run/media/$USER/myhome

Of course, you can name the mount directory anything you desire, within reason. Also, my home directory is on partition 1 of the disk, thus my /dev/sda1 entry. You'll want to put whatever drive and partition that your home directory is located in place of sda1.

What this does is it makes the soon-to-be home directory accessible to you before you mount it as your /home directory.

6) It is easier to do the next part in a file manager. Go into your newly mounted home drive, and go into the ".config" directory. If you don't see it, try pressing Ctrl-H. That will show all the hidden files. Those are all the directories and files that start with a period.

Once in, delete all the folders of past programs that you've used before or you no longer need. Don't worry here about removing something your system might need. Especially good to get rid of old DE directories like XFCE or KDE (which pretty much covers all directories and files that start with a "k"). The only config files and directories that should be remaining are of programs you are currently planning on using. 

For example, I have a file in the .config directory called kitty. it is a terminal application that I prefer using. But, if you fail to keep any config files, all it would mean is that you would have to start over setting up that program.

But the main thing is to delete or rename any desktop environment's configuration files, that will give your system a fresh "blank slate" to put its default setting into. If you don't find the setting file you are looking for in the $HOME/.config directory, check in your $HOME directory as a lot of programs will put their configuration files in there instead of the /.config directory.

Once I've done the above, I would then continue with the steps 1 - 5 above where ever you left off at. Once you've rebooted, you should log into your home directory with all your files intact, including the settings for your programs, yet it won't affect the desktop environment's settings in a bad way.

So, that is how I keep my desktop environment's settings while reusing my /home directory.

How to Deal with a "filter failed" error in CUPS

 I ran across this error recently when I installed a new Linux distribution on my writing computer called "Neptune OS", which is a Debian based distro. I spent about 2 days troubleshooting this problem, and I finally ran across the solution (at least in my case) that allowed me to print again.

So, installed this distro that I wanted to try out for my channel series: "New User Linux Reviews." I installed it, which went smooth enough, Then, in checking out the distro, one of the functions I check out was whether the system installed the printer (I have a network printer, a Brother MFC-L2710DW) or not, how easily it was to install it if it didn't, and did it work or not?

So when I went to check out the printer, I was pleasantly surprised to find the printer had been automatically detected and installed. So I initiated a test page print to see if it would print. Unfortunately, it didn't. And the only error message I found was "filter failed," which I discovered in my research could be caused by several different issues.

Probably the best troubleshooting guide that I found on the web was in the Arch Wiki:

https://wiki.archlinux.org/index.php/CUPS/Troubleshooting#CUPS:_%22Filter_failed%22 

It listed several of the major reasons it could give that error, as well as what to do about them, though it failed to give me a solution to my problem. Still, it pointed me in the right direction to figuring out, quite by accident, my solution.

After scouring the web for potential causes and solutions to this problem, and coming up empty handed, I realized that there wasn't much out on the web to help people address this issue (thus, the reason for this blog post). So after finding the Arch Wiki article mentioned above, I read through my error_log file in

/var/logs/cups/

That is when I discovered that the problem was an app called "pdftopdf" that it failed to create a "log file." Which created a cascade effect of other apps--that CUPS relies upon--to error out as well. Since some of those apps are also cups filters, it gave me the "filter failed" error in the print queue.

But, I still had to figure out what to do about it. After trying out a few other options, and they failed as well, I finally noticed one error message in the error_log file, which read: 

open /usr/share/cups/data/default-testpage.pdf: no such file or directory

On a whim, I decided to go to that directory and find out what was there. What I found were several pdf files that I realized were templates. However, what I also noticed was a file called

default-testpage.pdf.XXXXX

The "XXXXX" stands for some other letters that started with a "C" but I've already forgot exactly what they were (I'm not even sure about the "C" either). I wondered what would happen if I deleted  the extra letters from the end of that file so that it ended in "pdf," whether it might not find the file and print it. So I did that, then I went back to the printer queue and hit the "reprint" button: it printed!

Okay, so that meant that the CUPS system wasn't coordinating with what the printer was looking for as far as file names. I suspected it might be the CUPS system which was at fault, since I've had this printer for some time now, and have installed it on multiple systems without much issues, save for Arch distros, which while they install CUPS, rarely appear to have their daemon active, much less a GUI print manager application installed.

From that data, I wrongfully concluded that the two files I had noticed in that directory (default-testpage.pdf.XXXX, modified to default_testpage.pdf and file testprint which I had modified to testprint.pdf, were still there. I had assumed that these files were temp files that would disappear once they printed. I should have known better, however, that these were templates with names like "standard.pdf, secret.pdf, topsecret.pdf, classified.pdf and unclassified.pdf just to name a few of the other files in the directory.

However, what caused me to realize that bit of truth were the messages that now popped up on all three of the printers I had installed on the system that said something about a missing file, in bright red at the top, and they failed to even acknowledge that I had printed a test page, nothing in the print queue, nothing in the error_log file save something about not being able to create a profile or something along those lines. That is, once I deleted those two files.

So, what was I to do? That's when I wondered if my Linux Mint CUPS folders on my laptop might have the same list of files, like, maybe I could use those files? So I checked and they did have those same files. So I copied them all over to the same directory on my desktop, and guess what? Suddenly, the printers worked!

All I can figure was that one or more of those files were corrupted and/or the printer was looking for names that CUPS had given different names to use as templates. Not finding the expected template pdf file, it crashed. Once I changed the name of that one file, the printer was able to print the file. In copying over the files from a working copy of CUPS in this directory only, I somehow fixed the system.

So for everyone out there who has the same error in the error_log file, that could be your issue and solution as well.

May the Linux Force be with you!

 

UPDATE (3/14/21): I reinstalled the system and here is the file I noticed with the extra ending on it in the PDF templates that are in the /usr/share/cups/data directory:

default-testpage.pdf.distrib

I also printed out a normal text from the Kwrite program successfully, before I ever changed anything. The printer works out of the box. The only part that doesn't appear to work is the test page which should print out when you select "Print Test Page" under the maintenance button on the "Printers" section of the System Settings.

Once I had confirmed that everything else would print, I removed the ".distrib" ending so that the file read: default-testpage.pdf, which is exactly the file name that the error log said CUPS was looking for. Once I made that one change, it would print the test page just fine.

So, the bottom line is that to fix this apparent error, all one has to do is change the file name from:

default-testpage.pdf.distrib

to:

default-testpage.pdf

And you'll be good to go!

You can do that by entering the following command at a terminal prompt:

mv /usr/share/cups/data/default-testpage.pdf.distrib /usr/share/cups/data/default-testpage.pdf

May the Linux force be with you!

How to Use a Bash Script File

 A Bash script file is simply a file containing a list of commands as one might enter from a terminal command prompt, with the addition of some more programming options like If . . . then, for, and while statements. It can be made to do most any function on a Linux, Apple, or other Unix based operating systems. They can greatly simplify and automate certain tasks.

For example, on a Debian based system, to preform an upgrade from the terminal requires entering at least two lines of text-based commands into a terminal. First, one must do an update to update the repositories to ensure one has all the most recent changes to them. Then you accomplish the upgrade, so the terminal commands would look like this:

sudo apt update
sudo apt upgrade

To create a bash file, you open your favorite text editor and give it an appropriate name, like in this case we might name this file "aptup.sh"

Note, the "sh" extension is commonly used for bash script files, but unlike MSWindows, that doesn't make it executable for Linux. You could put any extension on there you want, or none at all.

Now, enter the following to create the bash file:

#!/bin/bash

# This is a script file to make updates simpler!

sudo apt-get update
sudo -y apt-get upgrade

exit

The first line is the same for every bash file. It essentially tells the system what program and where it is at that will run this file.

The second line is optional. It is a comment. Every line that begins with a # will be ignored by the bash program, except the very first line, of course. But it is a good practice to put a general purpose statement at the beginning of your file, if for no other reason, if you forget what this file does, it serves as a good reminder for you, and provides any introductory information for others who might look at your source code. You can put as many or as few comments in a file as you want, put them anywhere you desire, or none at all. As long as a line has a # before it, it will not be run by the system. As a matter of fact, putting a # before lines of code is a good way to not have them run without deleting them entirely.

On the update and upgrade commands, you'll notice two changes I've made from the initial "apt" commands above. First, I've used "apt-get" instead of "apt". Apt is designed to be run interactively by the user, where as apt-get has provisions for running inside a script.

The second change is adding in the -y option. This option allows the script to become more automated by assuming a "yes" answer to any yes/no questions it asks. Typically, an upgrade script will list out the files it intends to upgrade, then ask you if you want to proceed with the upgrade.

The last line is optional at the end of the file, but it is good practice to put it in. It tells the bash script to stop processing and exit the file. It becomes more necessary if you want to stop processing earlier in the script, like during an if . . . then statement.

Once you have saved the file, there are a couple more steps to turn this into an executable file.

One, you should put this file into a directory that is in your path statement. To discover what is in your PATH statement, enter the following into a terminal window:

echo $PATH

Yes, it needs to be in all caps. Variables in Linux are case-sensitive.

What this does is it allows you to run the program no matter where you are in your directory structure. Otherwise, you would have to enter the full path every time you ran the script: /usr/bin/aptup.sh instead of just aptup.sh

The logical place to place this file is in your /usr/bin directory. That will make it available to all users of the computer and is where the bulk of user based programs reside. Or you can put it in a home directory and add that directory to your PATH environment variable by doing the following steps:

I usually create a bin directory in my home folder. You can do this using your file manager, but I'll show you here how to accomplish it from the command line. This is where I put all my scripts.

Bonus Info: In Solus, you don't have to add the user home directory bin to the path statement. If you create the directory, it automatically picks it up and adds it for you!

To create the bin directory ensure you are in your home directory by entering:

cd ~

Then enter (unless you already have one):

mkdir ./bin

Then to enter it into you path variable, enter:

export PATH=$PATH:$HOME/bin

If you run it from a terminal, it will only be good for the life of that terminal session. To have it come up every time a new terminal session is started, enter that command in your .bashrc or .profile file, whichever your system uses to initialize a terminal session. For Debian based systems, that will generally be .bashrc

Two, you'll want to make your file executable. Like the above, you don't have to do this, as long as you wish to preface every command with "bash" and the full path to where the file is, even if it is in a path where your system looks for executable program files. It is an easy command to do. Enter:

chmod +x ~/bin/aptup.sh

To accomplish the same in most file managers. right-click on the file and select "properties" from the menu. Go to the "permissions" tab and make sure to check off the box "make file executable" or something similar.

Now you should be ready to use your script file by simply typing in the name: aptup.sh! And your system will get updated by one command instead of two.

How to Install Parrot OS

 I have installed Parrot OS, but despite the Calamaris installer, it ended up not being a simple event. I attempted to install the MATE security edition on a virtual Gnome Box machine. The installation went fine until when it was about 93% of the way done, it stopped and sat on the following command: /usr/sbin/sources-media -u. It sat on it until the 600 seconds was up. I tried installing it with different settings, and still it would hand up at that spot, only to force me to close the installation and failed to install the operating system.

While on the Live installation of the system, I decided to take a look at the file. I discovered that it was a script file, and that the -u switch caused it to go into an update. The switch activates the following commands:

if [ "$1" = "-u" ]; then
    umount $CHROOT/$MEDIUM_PATH
    rm $CHROOT/etc/apt/sources.list.d/debian-live-media.list || true
    chroot $CHROOT apt-get update
    exit 0
fi

The fourth line updates the new system, which can be done equally well either before or after you install the system. However, the reason it was hanging is because as of today, it required almost 1700 updates, which alone would go beyond the 600 seconds it allows it to finish. However, it also ask several questions and requires user interaction to finish. Which means that was why it was hanging up. With no movement as it sat there and waited for my input in vain since the system didn't provide a way for me to do that, naturally it would time out. And since there wasn't any provision made for that in the install process, it ends the installation with only 7% more to go. Also, due to the big amounts of updates, you can't update it before you start the install because there isn't enough room on the "USB", virtual though it may be, to do it.

So with the only option left to update after the install, I had to disable the update in order to finish the installation. So I commented out the update command line in the file by putting a "#" at the beginning of that line so that it now showed:

#    chroot $CHROOT apt-get update

That allowed it to bypass the update and finish the install. Then I was able to do the giant update manually. Here are the commands to do this.

To edit the file, use your favorite text editor to comment out the line as described above. My favorite is nano from the command line BEFORE you start the install process from the live boot up.

sudo nano /usr/sbin/sources-media

Once you boot up into your new system, you can start the upgrade process using the following commands from the terminal, which I recommend you use instead of the GUI interface to update this many files.

sudo apt update
sudo apt upgrade

Then check on it every once in a while because it will wait for your interaction at points. (Note: when you get to the section right after it downloads all the files and displays the change log to you with a ":" waiting for your input, you can just press enter until it tells you you can press "q" to exit it.)

Then enter the following command to remove unneeded files:

sudo apt autoremove

Once you've upgraded all the files, you're good to go!

How to Fix Non-free Software Error in Debian

 As I mentioned last time, there is some tweaking to do when Debian is installed. Recently, I discovered another needed tweak one needs to do, especially if you need "Non-free" software for some firmware, in my case for my wifi on my HP Laptop. Previously, I tried to install Debian on my HP Laptop, but encountered this error message, which meant I wouldn't be able to use my system. That's when I decided to install Linux Mint Debian Edition on my laptop instead, because I knew it would work.

But it confused me somewhat, because to me, "Non-free" means I need to shell out some money to buy software for, something. Unfortunately, the version of Debian I downloaded (a Cinnamon enabled package), failed to tell me exactly what needed the "non-free" software, and it was the middle of the night and I needed to finish up so I could get some sleep. But, I needed a working system the next day, which is why I installed Linux Mint, because I was sure it would work out of the box.

But, on my Acer Asprire laptop, I was able to install Debian just fine, using the net installer version, which hooks you up to the internet to download most of the packages. So I assumed it was the version of Debian I tried to install, and I tried to install Debian again using the net installer. Yet, again, it encountered this error when I tried to install it, but unlike the previous time, it told me what firmware I needed. So, with that error on my HP Laptop, I opened my Aspire laptop and did some research on this error. Here is what I found out.

I discovered that "non-free" doesn't mean that you have to buy anything--rather it means that the firmware is proprietary software. I read that Debian doesn't enable this "feature" out of the box due to concerns about "non-free" software on their distribution. I found out that to solve this issue, you simply need to edit your repository list file, and add some additional text to the end of each line in the file. Here is the procedure to fix this problem.

First, you need to use a text editor to edit the source.list file. You can use your favorite editor, or use the following command line in a terminal (ensure the user has sudo privileges):

sudo nano /etc/apt/sources.list

Then on the end of each line that begins with "deb", tack on the following words after the "main" keyword:

contrib non-free

For example, one line commonly found in this list would be

deb http://deb.debian.org/debian buster main

When you've edited it, it should look like:

deb http://deb.debian.org/debian buster main contrib non-free

Once you've done that to every line in the file that starts with "deb", save the file edits under the same name, then enter first:

sudo apt update

then us sudo apt install to install your firmware. In my case, it indicated that I needed the:

sudo apt install firmware-iwlwifi

package.  So, with that information, I went ahead with the install, hooking my HP laptop to an Ethernet connection for its internet access, which worked fine. Once I installed Debian, I was able to follow the above steps to install the "non-free" software, then I was able to set up my wifi without further incident and disconnect the Ethernet cable. I'm typing on my Debian system right now, even!

Thanks for reading.

PS: You can reedit the file and take those words off the end if you do fear downloading other proprietary software in the future.

How to Enable Adduser on Debian

 I prefer to use adduser over useradd when possible. It simply is more logical to my mind. One time when I installed Debian, though I knew it was a Debian based program, when I typed in:

sudo adduser

All I saw in return is the "Program not found" or something similar. I discovered after checking on it using:

which adduser

. . . that it resided in the /usr/sbin directory. After doing a check on the $PATH environment variable using:

sudo env

My suspicions were confirmed--that /usr/sbin was not in the $PATH variable. Why doesn't Debian put it there by default? Hard to say. It appears that they do have the /sbin directory in the path, which should point to /usr/sbin since it is a symbolic link At any rate, not knowing at the time how Linux processed the $PATH and where I should put it, I proceeded to do some research. In DOS, everything used to go into the Autoexec.bat file, which always was run on startup. 

To make a long story shorter, what I discovered was that one: There was one difference between how the DOS and Linux path statements were used. For Linux, the big difference is you put "export" before the PATH= part. So the statement to add to the appropriate file is:

export PATH=$PATH:/usr/sbin

All caps on the PATH part is important, and the colon separates each entry. Putting $PATH on the right side of the =, appends what you add to it. So if the PATH statement echos out "/usr/bin" the resulting output from the above export statement would be "/usr/bin:/usr/sbin". The "export" command makes it usable beyond this one instance which is what you want.

Two: Where to put it? That turned out to be more complicated that one might think. There were multiple files to try. There is a file to put it in if you want only one user to use it, another for all users on the system except for root, and yet another if you only want root to have access to it. On top of that, the file you put it in can differ between major distributions. Like the Mandrake version I saw given as an example that one website used ".bash_profile" whereas in Debian, it is ".bashrc".

Since I figured where as the user programs are mostly installed in the /usr/bin directory, which was included in the PATH by default, that the /usr/sbin directory contained programs that would be more system type files that should primarily be accessed by a root user. So obviously, it would go in the root's home directory, which is at /root as it turns out. So, you would want to enter the following to edit that file in the root home directory:

sudo nano /root/.bashrc

Then add the line at the end of the file:

export PATH=$PATH:/usr/sbin

When I did that, it worked when I attempted to access the program from root using sudo, but not as just a simple user.

(Note: the period it begins with means it is a hidden system file. Use Ctrl-H in your file manager to see it or "ls -a" if using the command line.)

You can use

sudo env

To verify that /usr/sbin is now part of the $PATH variable. Now you should be able to run

adduser --help

As well as any other programs in the /usr/sbin directory!

May the Linux force be with you!