Second Hard Drive Content

I have an SSD with OS 11.1 and had transferred and moved /usr to a second hard drive using Tar (tar -C /usr -cf - * | tar -C /newdisk -xvf -). However, ada0 seems that it's increasing in size while ada1 doesn't seem to be storing anything. Also, when trying to access ada1 (newdisk) claimed I don't have permission despite being root user. So, in researching seem to point to not having created a symbolic link...reading here: https://www.freebsd.org/cgi/man.cgi?query=link&sektion=2 doesn't show the command for one to easily understand and follow the description. So, from my understanding, would this work?

link (const char ada0/usr, const char ada1/usr

I take it that I would need the above Tar command to transfer /usr again before I symbolic link. After completing the link, will mv command remove /usr from ada0?
 
You need to give us more detail. You keep talking about disks ada0 and ada1. Your tar command pipeline above really does seem to copy files from /usr to /newdisk, modulo a few bugs, which I'll get to below). But files are not written to and read from disks, they are written/read from file systems. Did you create a file system on the new disk? Did you mount it?

Here is my theory: either you forgot to create a file system on your new disk, or you did but forgot to mount it. Then the pipe of two tar commands will work, but it will deposit everything in /newdisk/... on the old file system (because nothing has been mounted yet).

I have no idea what the discussion of softlinks (a.k.a. symbolic links) has to do with this, nor why you are quoting the C syntax of the link system call. If you think this is important, you need to explain this better.

And then, your tar pipeline has a nasty bug in the first half. You start with "tar -C /usr -cf -", which is sort of good: Start tar, and immediately change the working directory of that running tar command to be /usr, then begin tar'ing things up and write them to stdout (that's the lonely "-" parameter). Excellent. But then the next thing on your command line is "*", which means: in the current directory you are in when the hit enter, make a list of all files and directories, and feed those into tar as arguments. Unfortunately, there is no guarantee that at this point you are in the /usr directory at all (you might be, you might also somewhere else. Here is what I would write: "cd /usr; tar -cf - . | tar -C /newdisk -xf -".

And in reality, I would not actually use tar. I would use rsync, since it is easier to use, and no slower: "rsync -a /usr/ /newdisk/" (note the trailing slashes on the names). You can issue that command from any directory. You can even add "-v", and see how it makes progress, without interfering with the copying.
 
You need to give us more detail. You keep talking about disks ada0 and ada1. Your tar command pipeline above really does seem to copy files from /usr to /newdisk, modulo a few bugs, which I'll get to below). But files are not written to and read from disks, they are written/read from file systems. Did you create a file system on the new disk? Did you mount it?

Here is my theory: either you forgot to create a file system on your new disk, or you did but forgot to mount it. Then the pipe of two tar commands will work, but it will deposit everything in /newdisk/... on the old file system (because nothing has been mounted yet).

I have no idea what the discussion of softlinks (a.k.a. symbolic links) has to do with this, nor why you are quoting the C syntax of the link system call. If you think this is important, you need to explain this better.

And then, your tar pipeline has a nasty bug in the first half. You start with "tar -C /usr -cf -", which is sort of good: Start tar, and immediately change the working directory of that running tar command to be /usr, then begin tar'ing things up and write them to stdout (that's the lonely "-" parameter). Excellent. But then the next thing on your command line is "*", which means: in the current directory you are in when the hit enter, make a list of all files and directories, and feed those into tar as arguments. Unfortunately, there is no guarantee that at this point you are in the /usr directory at all (you might be, you might also somewhere else. Here is what I would write: "cd /usr; tar -cf - . | tar -C /newdisk -xf -".

And in reality, I would not actually use tar. I would use rsync, since it is easier to use, and no slower: "rsync -a /usr/ /newdisk/" (note the trailing slashes on the names). You can issue that command from any directory. You can even add "-v", and see how it makes progress, without interfering with the copying.


Thank you ralphbsz for responding...yes, I did created a file system and mounted the new hard drive...that's why I was surprised that I can see the new drive mounted yet I don't have permission to access it. I was thinking that somehow there might not be linked (symbolic)

Yes, I did changed directory first (cd /usr) before the final command...a "BUG"...I had gotten the Tar command from here: https://forums.freebsd.org/threads/62272/

So, the "rsync -a /usr/ /newdisk/ -v" would move the /usr to the newdisk and the OS knows where it is? With the Tar command, I could watch the files processing...I did this back in Dec...I am new to FreeBSD and my brain tends to resist the command. I followed here to format the drive and set up file system as well as mount: https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/disks-adding.html
 
First let's assume your using UFS and have /dev/ada0 which contains FreeBSD and /dev/ada1, the new disk which now has a single filesystem and contains the same data as /usr on /dev/ada0.
So to move the data from /usr to the new harddisk you mounted /dev/ada1 on /mnt I guess.
Have you created an entry in /etc/fstab like the following and rebooted?
Code:
/dev/ada1p1        /usr    ufs    rw    2    2
If you have /usr on a separate partition on /dev/ada0 as well, you have to comment that line...
There shouldn't be any softlinks involved ;)
 
Like k.jacker said: No soft links needed!

And to be completely clear, this is a three-step process:
  • Create new (empty) file system on new disk. Mount new file system somewhere, for example /newdisk (using /mnt would be more traditional, but you can use /newdisk if you like). Copy data from /usr to /newdisk. Now you have two copies of the data. Watch the output of df while this is running: the old file system that contains /usr will not get more full, while the new one will slowly have space used.
  • Now comes the scary part: Once you have verified that everything has been copied correctly, and that /newdisk has a complete set of files (with good permissions and ownership), you have to delete all the files from /usr. At this moment, you have nothing, and the system won't work right, so do this while in single-user mode. Do df again, and the space usage on the old file system should go down.
  • Now dismount the new file system from /newdisk, and mount it at /usr, like k.jacker explained with the line in /etc/fstab.
Since the second step is scary, you can do a test-run of the third step (unmount and mount), and make sure everything works. And you need to be 100% sure you have unmounted /newdisk again before doing the delete (otherwise you'll end up deleting the new copy). Sadly, the way file systems and mount points are designed, there is no way to delete the old stuff from /usr while the new disk is already mounted.

... I can see the new drive mounted yet I don't have permission to access it. ...
That's bad. Why don't you have permission to access it? You are running this as root, aren't you? Perhaps you mounted it wrong?

If you didn't have permission to access it while doing the copy, then probably the copy didn't work! Check that.

So, the "rsync -a /usr/ /newdisk/ -v" would move the /usr to the newdisk and the OS knows where it is?

Careful. The rsync alone does exactly what your pipeline with two tar commands does. This is not a "move", it is a copy. The move happens in steps: First copy (that's what the tar or rsync does), then delete old one.
 
First let's assume your using UFS and have /dev/ada0 which contains FreeBSD and /dev/ada1, the new disk which now has a single filesystem and contains the same data as /usr on /dev/ada0.
So to move the data from /usr to the new harddisk you mounted /dev/ada1 on /mnt I guess.
Have you created an entry in /etc/fstab like the following and rebooted?
Code:
/dev/ada1p1        /usr    ufs    rw    2    2
If you have /usr on a separate partition on /dev/ada0 as well, you have to comment that line...
There shouldn't be any softlinks involved ;)

Thank you K.Jacker for responding...I remembered back in last Dec. when I did the UFS setup per here: https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/disks-adding.html and got to the final step
Code:
/dev/ada1p1        /usr    ufs    rw    2    2
upon execution, I got dev/ada1p1: permission denied. Of course, I was surprised as I am the sole root user. So, I tried manually (mount newdisk) and the drive mounted...so, I followed through with the Tar command above and watched the screen showing the transfer.
 
Yes, something is definitely wrong...tried to unmount the drive (umount newdisk) got statfs: no such file or directory...so, I'll have open the computer and physically unplug the drive...reboot then a shutdown again before I attach the drive again. (gpart show) shows the partitioned drive though.
 
K.jacker...these are the output:
 

Attachments

  • Screen Shot 2018-03-02 at 4.40.22 PM.png
    Screen Shot 2018-03-02 at 4.40.22 PM.png
    27.1 KB · Views: 207
  • Screen Shot 2018-03-02 at 4.43.16 PM.png
    Screen Shot 2018-03-02 at 4.43.16 PM.png
    15.8 KB · Views: 234
OK, the gpart show tells us a little bit. Only that the disk you ran the command on has a single partition, which is a UFS file system. Given that this is disk ada1, it is most likely the new disk (please confirm this). We still don't know for sure whether there is really a file system on the partition ada1s1, nor whether it is mounted. Please run the mount command; the output from df wouldn't hurt either.

And the output for /etc/fstab only shows us that something is wrong with your permissions. Most likely, the account you are logged in as is not root. But the strange thing is that the default permissions for /etc/fstab are to be world-readable, so something is fishy here. Please log in as root, show us the content of that file, and also the output of "ls -l /etc/fstab", so we can check what's wrong with ownership and permission bit to give to "permission denied".
 
Ralphbsz, yes, ada0 is the OS and ada1 is the newdisk. Here are some outputs:

When I type su I get the # prompt without password. I also have one admin user with password whom I thought was also root user. So, it seems that admin is not also root. How could I just implement su with password? I don't want to go through adding user...I am the only one that have access to the computer.
 

Attachments

  • Screen Shot 2018-03-02 at 5.44.28 PM.png
    Screen Shot 2018-03-02 at 5.44.28 PM.png
    18.4 KB · Views: 206
  • Screen Shot 2018-03-02 at 5.51.37 PM.png
    Screen Shot 2018-03-02 at 5.51.37 PM.png
    47.6 KB · Views: 189
  • Screen Shot 2018-03-02 at 5.58.21 PM.png
    Screen Shot 2018-03-02 at 5.58.21 PM.png
    45 KB · Views: 202
  • Screen Shot 2018-03-02 at 6.03.37 PM.png
    Screen Shot 2018-03-02 at 6.03.37 PM.png
    15.8 KB · Views: 198
Ralphbsz, yes, ada0 is the OS and ada1 is the newdisk.
And that looks good. Both have file systems, both are mounted. The permissions from /etc/fstab look normal too.

When I type su I get the # prompt without password.
Weird. Does your root account have a password? Find a text console, try to log on as root: does it ask you for a password? If not, then I'm amazed that you managed to install and configure the OS without a root password.

By the way, if that is true: IMMEDIATELY select a good root password, write it down in a safe place (not on a yellow sticker in your wallet or on the edge of the monitor), and change the root password, with the passwrd command.

I also have one admin user with password whom I thought was also root user. So, it seems that admin is not also root.
You need to explain more. Where did the admin user come from? What is their user ID? The usual definition of "root" is: the user whose user ID and group ID is zero. Please look at your /etc/passwd file; the user ID and group ID are the 3rd and 4th field of each line. If the admin user has non-zero user ID, it will not work well to administrate the system.

Another question: Why are you using an admin user? Why not just use root directly? If you change the user/group ID of the admin user to be 0, they are de facto identical to root, just with a different name. That's just unneeded complexity. (See footnote below.)

I don't want to go through adding user...I am the only one that have access to the computer.
In that case, you should have exactly two user accounts that one can log into (in addition to a whole lot of pseudo-accounts in /etc/passwd: One for your normal, user-level work (like browsing the web, sending e-mail, practicing programming, ...), and root. Nothing else is needed. In the future, you might want to add more user accounts for when you take on different roles; for example, I have two user accounts on my machine, one for normal home stuff, another for when I have to use my home computer for work-related stuff.

(Now the footnote. There is actually a tradition of having multiple "root" accounts. One is typically spelled "toor", and may use a different log-in shell, for example ksh instead of tcsh. But they have the same user/group ID and home directory, just different log in shells. The Unix notion of "user" is a little confusing; there is the user name that's typed into the login, there is the user/group ID number, and there is the home directory, and those don't necessarily have to have 1-to-1 correspondence. Please ignore this footnote if it confuses you.)
 
Ralphbsz, I have added a password. When I had first setup the machine, I had two user...something when wrong and I can't remember as I had reinstalled the OS. The admin user is via a web interface.

I realized I got the answer I was seeking with both commands (df and df -h) as the pics above shown. Indeed, newdisk is storing the /usr file...it just needs to be at least 4GB to show percentage. So now, I just need to figure out what's going on with permissions.
 
So what exactly is the problem here? I tried to check the thread but I'm having a really hard time trying to understand what's wrong.

For example: when you mentioned that you got an error message "permission denied" you linked to an URL and stated that you followed those instructions. However, that webpage lists dozens of instructions, so there's no way for us to tell what command gave you that error. You really need to be more precise about such things, otherwise it's pretty much impossible to provide any help,

Re-reading I now get the impression that you actually tried to execute /etc/fstab but that is obviously impossible because /etc/fstab is not some kind of executable, it's a config file.

Still, bottom line, what exactly is going wrong for you right now?
 
I second that. It looks like you are not editing /etc/fstab. Either use vi or ee /etc/fstab
permission denied because it's not executable. It's a config file.
What is the GUI crutch you are fighting here?
 
Re-reading I now get the impression that you actually tried to execute /etc/fstab but that is obviously impossible because /etc/fstab is not some kind of executable, it's a config file.

I second that. It looks like you are not editing /etc/fstab. Either use vi or ee /etc/fstab
permission denied because it's not executable. It's a config file.
What is the GUI crutch you are fighting here?

Thank you Shelluser and Phishfry for responding and for pointing out that /etc/fstab is a config file...so now, all I need to do is edit to correct permission...all problem solved. I am new to FreeBSD and Shell.
 
Back
Top