Hi, I recently bought a 1TB hard drive to add in to my computer. My drives will be dev/sda, a SSD which presently contains Leap 15.4 / and /home. dev/sdb is a standard drive, which contains Win 10 and Win XP. The third drive will be /dev/sdc, which will be the new 1TB drive. I want to move the Leap 15.4 /home from the SSD drive (dev/sda) to the 1TB drive (dev/sdc). I think the way to do this is as follows, but I'm asking the list to check this out to make sure I've got it correct. #fdisk -l (to identify the disks and make sure I've got the correct discs planned out) Then I will create a partition on /dev/sdc and format it. #mount /dev/sdc1 /mnt (Once I've made and formatted the partition on the new drive, I will need to mount it.) #cd /mnt (to see if I can change directories to the new filesystem) #ls -ahl (to see what is in the new filesystem) #rm -rf lost+found (remove the lost+found directory) #cp -rp /home/* /mnt (copy the home directory to the new filesystem on the new harddrive) #ls (to find out that everything is copied) #mv /home /home.orig (rename old home directory) #mkdir /home (make a new home directory) #cd / #umount /dev/sdc1 #mount /dev/sdc1 /home/ (to mount the new home directory) #cd / #cd ~ #pwd #ls #cd /home #ls #cd (my home name) #ls #ls -a (to make sure everything that is supposed to be in /home is there) #cp /etc/fstab /etc/fstab.org #gedit /etc/fstab Add a line at the bottom of the file to mount the new /home directory Type the name of the partition at the start of the line, and then press Tab. (dev/sdc1) Type the mount point, /home, and press Tab. Type the filesystem description ext4, and press Tab. Type defaults for the mount options, and press Tab. Type the digit 0 for the filesystem dump option, and press Tab. Type the digit 0 for the filesystem check option. It should look like this when done: /dev/sdc1 /home ext4 defaults 0 0 Then save the file. Then #reboot now Then once rebooted #df /dev/sdc1 (check that it's mounted on /home) If everything is good, then: #cd / #rm -rf home.org/ Look good? Thanks Mark
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2022-11-18 at 10:04 -0500, Mark Misulich wrote:
Hi, I recently bought a 1TB hard drive to add in to my computer. My drives will be dev/sda, a SSD which presently contains Leap 15.4 / and /home. dev/sdb is a standard drive, which contains Win 10 and Win XP. The third drive will be /dev/sdc, which will be the new 1TB drive.
I want to move the Leap 15.4 /home from the SSD drive (dev/sda) to the 1TB drive (dev/sdc). I think the way to do this is as follows, but I'm asking the list to check this out to make sure I've got it correct.
#fdisk -l (to identify the disks and make sure I've got the correct discs planned out)
lsblk --output NAME,KNAME,RA,RM,RO,PARTFLAGS,SIZE,TYPE,FSTYPE,LABEL,PARTLABEL,PTTYPE,MOUNTPOINT,UUID,PARTUUID,WWN,MODEL,ALIGNMENT | less -S Gives a very complete information.
Then I will create a partition on /dev/sdc and format it.
#mount /dev/sdc1 /mnt (Once I've made and formatted the partition on the new drive, I will need to mount it.)
#cd /mnt (to see if I can change directories to the new filesystem)
#ls -ahl (to see what is in the new filesystem)
#rm -rf lost+found (remove the lost+found directory)
No.
#cp -rp /home/* /mnt (copy the home directory to the new filesystem on the new harddrive)
rsync --archive --acls --xattrs --hard-links --sparse --stats --human-readable --one-file-system \ /home /mnt Do it twice. The second time, do it in text mode, in tty1, and make sure to log out of the GUI. And add a "--del", very carefully. Actually, you could do an "init 3" before the second time. Why twice? Because it takes very long, hours, and during the first time you can be using your computer.
#ls (to find out that everything is copied)
Use mc, compare directory sizes.
#mv /home /home.orig (rename old home directory)
#mkdir /home (make a new home directory)
Add an entry in /ect/fstab for /home at this point.
#cd / #umount /dev/sdc1 #mount /dev/sdc1 /home/ (to mount the new home directory)
Just mount /home
#cd / #cd ~
No, because you are root. '~' will be /root
#pwd #ls
#cd /home #ls #cd (my home name) #ls #ls -a (to make sure everything that is supposed to be in /home is there)
#cp /etc/fstab /etc/fstab.org #gedit /etc/fstab
No, do it earlier.
Add a line at the bottom of the file to mount the new /home directory Type the name of the partition at the start of the line, and then press Tab. (dev/sdc1) Type the mount point, /home, and press Tab. Type the filesystem description ext4, and press Tab. Type defaults for the mount options, and press Tab. Type the digit 0 for the filesystem dump option, and press Tab. Type the digit 0 for the filesystem check option.
It should look like this when done: /dev/sdc1 /home ext4 defaults 0 0
Then save the file.
It is up to you what type to use for /home, but xfs seems to be preferred. I use "1 1", not "0 0". I also add "lazytime" (specially if it is ssd). Maybe "norelatime".
Then #reboot now
No need.
Then once rebooted #df /dev/sdc1 (check that it's mounted on /home)
If everything is good, then: #cd / #rm -rf home.org/
No. Give it a week :-)
Look good? Thanks Mark
Yes, just some details :-) - -- Cheers, Carlos E. R. (from openSUSE 15.3 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCY3fEyhwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVblAAnR8nvtm4+VL8Ojbf6JFK HK4+JLH1AJ9RNjLtijzv2DC9bFEOdMuul1wZGg== =FF64 -----END PGP SIGNATURE-----
On 2022-11-18 19:08, Andrei Borzenkov wrote:
On Friday, 2022-11-18 at 10:04 -0500, Mark Misulich wrote:
...
It should look like this when done: /dev/sdc1 /home ext4 defaults 0 0
Device names /dev/sdX may change after reboot. Never use them for long term stable reference, use UUID or LABEL.
Absolutely! I forgot that. It is important. The label can be created when the partition is formatted. You can use yast, or gparted, or the CLI. -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
Carlos E. R. composed on 2022-11-18 18:45 (UTC+0100):
Add a line at the bottom of the file to mount the new /home directory Type the name of the partition at the start of the line, and then press Tab. (dev/sdc1) Type the mount point, /home, and press Tab. Type the filesystem description ext4, and press Tab. Type defaults for the mount options, and press Tab. Type the digit 0 for the filesystem dump option, and press Tab. Type the digit 0 for the filesystem check option.
It should look like this when done: /dev/sdc1 /home ext4 defaults 0 0
Then save the file.
It is up to you what type to use for /home, but xfs seems to be preferred.
I use "1 1", not "0 0". I also add "lazytime" (specially if it is ssd). Maybe "norelatime".
When this system was originally installed as 42.1, The YaST installer made home 1 2. I've since changed it to 0 2. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On 2022-11-18 20:35, Felix Miata wrote:
Carlos E. R. composed on 2022-11-18 18:45 (UTC+0100):
Add a line at the bottom of the file to mount the new /home directory Type the name of the partition at the start of the line, and then press Tab. (dev/sdc1) Type the mount point, /home, and press Tab. Type the filesystem description ext4, and press Tab. Type defaults for the mount options, and press Tab. Type the digit 0 for the filesystem dump option, and press Tab. Type the digit 0 for the filesystem check option.
It should look like this when done: /dev/sdc1 /home ext4 defaults 0 0
Then save the file.
It is up to you what type to use for /home, but xfs seems to be preferred.
I use "1 1", not "0 0". I also add "lazytime" (specially if it is ssd). Maybe "norelatime".
When this system was originally installed as 42.1, The YaST installer made home 1 2. I've since changed it to 0 2.
The first digit doesn't currently have any effect, because nobody uses the command "dump". I don't even have it installed... And some filesystems do not support it, anyway. I think xfs doesn't. Maybe btrfs neither. I have it to 1 because, if one year I want to use dump, I see no reason to not dump a particular partition. I have never done it, anyway, since I started with Linux in 1998. -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
From: "Carlos E. R." <robin.listas@telefonica.net> Date: Fri, 18 Nov 2022 18:45:45 +0100 (CET) On Friday, 2022-11-18 at 10:04 -0500, Mark Misulich wrote:
Hi, I recently bought a 1TB hard drive to add in to my computer. My drives will be dev/sda, a SSD which presently contains Leap 15.4 / and /home. dev/sdb is a standard drive, which contains Win 10 and Win XP. The third drive will be /dev/sdc, which will be the new 1TB drive . . .
. . .
#cp /etc/fstab /etc/fstab.org #gedit /etc/fstab
No, do it earlier. To refine what Carlos said, it makes life easier if you add a line in /etc/fstab for the new /home partition earlier, as /home.new, so it looks something like this: /dev/sda3 /home ext4 defaults 0 0 /dev/sdc1 /home.new ext4 defaults 0 0 Then after you move the data, you can edit /etc/fstab again to change /home to /home.old (creating the mount point of course) and /home.new to /home and simply reboot. No explicit mounts or unmounts required, and you don't even need to log out as you until then. And instead of rsync, I would recommend doing the copy by making a backup on /home.old, verifying it there, restoring it on /home.new, and verifying it there as well (which also proves the backup is good). -- Bob Rogers http://www.rgrjr.com/
On 2022-11-19 06:13, Bob Rogers wrote:
From: "Carlos E. R." <robin.listas@telefonica.net> Date: Fri, 18 Nov 2022 18:45:45 +0100 (CET)
On Friday, 2022-11-18 at 10:04 -0500, Mark Misulich wrote:
> Hi, > I recently bought a 1TB hard drive to add in to my computer. My drives > will be dev/sda, a SSD which presently contains Leap 15.4 / and /home. > dev/sdb is a standard drive, which contains Win 10 and Win XP. The > third drive will be /dev/sdc, which will be the new 1TB drive . . .
. . .
> #cp /etc/fstab /etc/fstab.org > #gedit /etc/fstab
No, do it earlier.
To refine what Carlos said, it makes life easier if you add a line in /etc/fstab for the new /home partition earlier, as /home.new, so it looks something like this:
/dev/sda3 /home ext4 defaults 0 0 /dev/sdc1 /home.new ext4 defaults 0 0
Then after you move the data, you can edit /etc/fstab again to change /home to /home.old (creating the mount point of course) and /home.new to /home and simply reboot. No explicit mounts or unmounts required, and you don't even need to log out as you until then.
Remember that you have to change fstab with affected partitions not mounted.
And instead of rsync, I would recommend doing the copy by making a backup on /home.old, verifying it there, restoring it on /home.new, and verifying it there as well (which also proves the backup is good).
Doing a backup, how? Because I do backups with resync precisely the way I posted :-) -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
On Sat, 19 Nov 2022 12:19:38 +0100 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 2022-11-19 06:13, Bob Rogers wrote:
From: "Carlos E. R." <robin.listas@telefonica.net> Date: Fri, 18 Nov 2022 18:45:45 +0100 (CET)
On Friday, 2022-11-18 at 10:04 -0500, Mark Misulich wrote:
> Hi, > I recently bought a 1TB hard drive to add in to my computer. > My drives will be dev/sda, a SSD which presently contains > Leap 15.4 / and /home. dev/sdb is a standard drive, which > contains Win 10 and Win XP. The third drive will > be /dev/sdc, which will be the new 1TB drive . . .
. . .
> #cp /etc/fstab /etc/fstab.org > #gedit /etc/fstab
No, do it earlier.
To refine what Carlos said, it makes life easier if you add a line in /etc/fstab for the new /home partition earlier, as /home.new, so it looks something like this:
/dev/sda3 /home ext4 defaults 0 0 /dev/sdc1 /home.new ext4 defaults 0 0
Then after you move the data, you can edit /etc/fstab again to change /home to /home.old (creating the mount point of course) and /home.new to /home and simply reboot. No explicit mounts or unmounts required, and you don't even need to log out as you until then.
Remember that you have to change fstab with affected partitions not mounted.
Eh, why? I've never done that. AFAIK you can edit fstab whenever you like. Nothing looks at it until you execute some command that uses it.
And instead of rsync, I would recommend doing the copy by making a backup on /home.old, verifying it there, restoring it on /home.new, and verifying it there as well (which also proves the backup is good).
Doing a backup, how?
Because I do backups with resync precisely the way I posted :-)
On 2022-11-19 12:51, Dave Howorth wrote:
On Sat, 19 Nov 2022 12:19:38 +0100 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 2022-11-19 06:13, Bob Rogers wrote:
From: "Carlos E. R." <robin.listas@telefonica.net> Date: Fri, 18 Nov 2022 18:45:45 +0100 (CET)
On Friday, 2022-11-18 at 10:04 -0500, Mark Misulich wrote:
> Hi, > I recently bought a 1TB hard drive to add in to my computer. > My drives will be dev/sda, a SSD which presently contains > Leap 15.4 / and /home. dev/sdb is a standard drive, which > contains Win 10 and Win XP. The third drive will > be /dev/sdc, which will be the new 1TB drive . . .
. . .
> #cp /etc/fstab /etc/fstab.org > #gedit /etc/fstab
No, do it earlier.
To refine what Carlos said, it makes life easier if you add a line in /etc/fstab for the new /home partition earlier, as /home.new, so it looks something like this:
/dev/sda3 /home ext4 defaults 0 0 /dev/sdc1 /home.new ext4 defaults 0 0
Then after you move the data, you can edit /etc/fstab again to change /home to /home.old (creating the mount point of course) and /home.new to /home and simply reboot. No explicit mounts or unmounts required, and you don't even need to log out as you until then.
Remember that you have to change fstab with affected partitions not mounted.
Eh, why? I've never done that. AFAIK you can edit fstab whenever you like. Nothing looks at it until you execute some command that uses it.
If you have /dev/sda3 /home ext4 defaults 0 0 /dev/sdc1 /home.new ext4 defaults 0 0 and change to: /dev/sda3 /home.old ext4 defaults 0 0 /dev/sdc1 /home ext4 defaults 0 0 You have problems when trying to mount the second version. -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
On Sat, 19 Nov 2022 13:07:55 +0100 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 2022-11-19 12:51, Dave Howorth wrote:
On Sat, 19 Nov 2022 12:19:38 +0100 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 2022-11-19 06:13, Bob Rogers wrote:
From: "Carlos E. R." <robin.listas@telefonica.net> Date: Fri, 18 Nov 2022 18:45:45 +0100 (CET)
On Friday, 2022-11-18 at 10:04 -0500, Mark Misulich wrote:
> Hi, > I recently bought a 1TB hard drive to add in to my > computer. My drives will be dev/sda, a SSD which presently > contains Leap 15.4 / and /home. dev/sdb is a standard > drive, which contains Win 10 and Win XP. The third drive > will be /dev/sdc, which will be the new 1TB drive . . .
. . .
> #cp /etc/fstab /etc/fstab.org > #gedit /etc/fstab
No, do it earlier.
To refine what Carlos said, it makes life easier if you add a line in /etc/fstab for the new /home partition earlier, as /home.new, so it looks something like this:
/dev/sda3 /home ext4 defaults 0 0 /dev/sdc1 /home.new ext4 defaults 0 0
Then after you move the data, you can edit /etc/fstab again to change /home to /home.old (creating the mount point of course) and /home.new to /home and simply reboot. No explicit mounts or unmounts required, and you don't even need to log out as you until then.
Remember that you have to change fstab with affected partitions not mounted.
Eh, why? I've never done that. AFAIK you can edit fstab whenever you like. Nothing looks at it until you execute some command that uses it.
If you have
/dev/sda3 /home ext4 defaults 0 0 /dev/sdc1 /home.new ext4 defaults 0 0
and change to:
/dev/sda3 /home.old ext4 defaults 0 0 /dev/sdc1 /home ext4 defaults 0 0
You have problems when trying to mount the second version.
I don't see why. In this case, since you're changing /home it'll probably be easiest to make the changes to fstab and then reboot. But if you made sure you weren't logged in as a normal user then # umount /dev/sda3 # umount /dev/sdc1 # mount /dev/sda3 # mount /dev/sdc1 should work.
On 2022-11-19 16:09, Dave Howorth wrote:
On Sat, 19 Nov 2022 13:07:55 +0100 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 2022-11-19 12:51, Dave Howorth wrote:
On Sat, 19 Nov 2022 12:19:38 +0100 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 2022-11-19 06:13, Bob Rogers wrote:
From: "Carlos E. R." <robin.listas@telefonica.net> Date: Fri, 18 Nov 2022 18:45:45 +0100 (CET)
On Friday, 2022-11-18 at 10:04 -0500, Mark Misulich wrote:
> Hi, > I recently bought a 1TB hard drive to add in to my > computer. My drives will be dev/sda, a SSD which presently > contains Leap 15.4 / and /home. dev/sdb is a standard > drive, which contains Win 10 and Win XP. The third drive > will be /dev/sdc, which will be the new 1TB drive . . .
. . .
> #cp /etc/fstab /etc/fstab.org > #gedit /etc/fstab
No, do it earlier.
To refine what Carlos said, it makes life easier if you add a line in /etc/fstab for the new /home partition earlier, as /home.new, so it looks something like this:
/dev/sda3 /home ext4 defaults 0 0 /dev/sdc1 /home.new ext4 defaults 0 0
Then after you move the data, you can edit /etc/fstab again to change /home to /home.old (creating the mount point of course) and /home.new to /home and simply reboot. No explicit mounts or unmounts required, and you don't even need to log out as you until then.
Remember that you have to change fstab with affected partitions not mounted.
Eh, why? I've never done that. AFAIK you can edit fstab whenever you like. Nothing looks at it until you execute some command that uses it.
If you have
/dev/sda3 /home ext4 defaults 0 0 /dev/sdc1 /home.new ext4 defaults 0 0
and change to:
/dev/sda3 /home.old ext4 defaults 0 0 /dev/sdc1 /home ext4 defaults 0 0
You have problems when trying to mount the second version.
I don't see why. In this case, since you're changing /home it'll probably be easiest to make the changes to fstab and then reboot. But if you made sure you weren't logged in as a normal user then
# umount /dev/sda3 # umount /dev/sdc1 # mount /dev/sda3 # mount /dev/sdc1
should work.
Without rebooting, one can just umount homes, change fstab, mount homes again. And doing it this way you test that fstab is correct. If not, it is a pain on reboot. -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
On Sat, 19 Nov 2022 18:42:39 +0100 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 2022-11-19 16:09, Dave Howorth wrote:
On Sat, 19 Nov 2022 13:07:55 +0100 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 2022-11-19 12:51, Dave Howorth wrote:
On Sat, 19 Nov 2022 12:19:38 +0100 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 2022-11-19 06:13, Bob Rogers wrote:
From: "Carlos E. R." <robin.listas@telefonica.net> Date: Fri, 18 Nov 2022 18:45:45 +0100 (CET)
On Friday, 2022-11-18 at 10:04 -0500, Mark Misulich wrote:
> Hi, > I recently bought a 1TB hard drive to add in to my > computer. My drives will be dev/sda, a SSD which > presently contains Leap 15.4 / and /home. dev/sdb is a > standard drive, which contains Win 10 and Win XP. The > third drive will be /dev/sdc, which will be the new 1TB > drive . . .
. . .
> #cp /etc/fstab /etc/fstab.org > #gedit /etc/fstab
No, do it earlier.
To refine what Carlos said, it makes life easier if you add a line in /etc/fstab for the new /home partition earlier, as /home.new, so it looks something like this:
/dev/sda3 /home ext4 defaults 0 0 /dev/sdc1 /home.new ext4 defaults 0 0
Then after you move the data, you can edit /etc/fstab again to change /home to /home.old (creating the mount point of course) and /home.new to /home and simply reboot. No explicit mounts or unmounts required, and you don't even need to log out as you until then.
Remember that you have to change fstab with affected partitions not mounted.
Eh, why? I've never done that. AFAIK you can edit fstab whenever you like. Nothing looks at it until you execute some command that uses it.
If you have
/dev/sda3 /home ext4 defaults 0 0 /dev/sdc1 /home.new ext4 defaults 0 0
and change to:
/dev/sda3 /home.old ext4 defaults 0 0 /dev/sdc1 /home ext4 defaults 0 0
You have problems when trying to mount the second version.
I don't see why. In this case, since you're changing /home it'll probably be easiest to make the changes to fstab and then reboot. But if you made sure you weren't logged in as a normal user then
# umount /dev/sda3 # umount /dev/sdc1 # mount /dev/sda3 # mount /dev/sdc1
should work.
Without rebooting, one can just umount homes, change fstab, mount homes again. And doing it this way you test that fstab is correct. If not, it is a pain on reboot.
You seem to be agreeing with me now, since our disagreement is about whether you can change fstab whilst the affected filesystems are mounted. But you can't just umount /home, as Bob points out subsequently, if you're logged in as a normal user and thus with a home directory in /home since this means that /home is busy in that case and it can't be umounted. You need to be logged in as e.g root, not just use su or sudo. Which is exactly what I said. But/and there is no need to umount the filesystems first, you can leave them mounted whilst you edit fstab. The critical point is that you can't umount a busy filesystem; nothing to do with editing fstab.
On 2022-11-20 02:24, Dave Howorth wrote:
On Sat, 19 Nov 2022 18:42:39 +0100 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 2022-11-19 16:09, Dave Howorth wrote:
On Sat, 19 Nov 2022 13:07:55 +0100 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 2022-11-19 12:51, Dave Howorth wrote:
On Sat, 19 Nov 2022 12:19:38 +0100 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 2022-11-19 06:13, Bob Rogers wrote: > From: "Carlos E. R." <robin.listas@telefonica.net> > Date: Fri, 18 Nov 2022 18:45:45 +0100 (CET) > > On Friday, 2022-11-18 at 10:04 -0500, Mark Misulich wrote: > > > Hi, > > I recently bought a 1TB hard drive to add in to my > > computer. My drives will be dev/sda, a SSD which > > presently contains Leap 15.4 / and /home. dev/sdb is a > > standard drive, which contains Win 10 and Win XP. The > > third drive will be /dev/sdc, which will be the new 1TB > > drive . . . > > . . . > > > #cp /etc/fstab /etc/fstab.org > > #gedit /etc/fstab > > No, do it earlier. > > To refine what Carlos said, it makes life easier if you add a > line in /etc/fstab for the new /home partition earlier, > as /home.new, so it looks something like this: > > /dev/sda3 /home ext4 defaults 0 0 > /dev/sdc1 /home.new ext4 defaults 0 0 > > Then after you move the data, you can edit /etc/fstab again to > change /home to /home.old (creating the mount point of course) > and /home.new to /home and simply reboot. No explicit mounts or > unmounts required, and you don't even need to log out as you > until then.
Remember that you have to change fstab with affected partitions not mounted.
Eh, why? I've never done that. AFAIK you can edit fstab whenever you like. Nothing looks at it until you execute some command that uses it.
If you have
/dev/sda3 /home ext4 defaults 0 0 /dev/sdc1 /home.new ext4 defaults 0 0
and change to:
/dev/sda3 /home.old ext4 defaults 0 0 /dev/sdc1 /home ext4 defaults 0 0
You have problems when trying to mount the second version.
I don't see why. In this case, since you're changing /home it'll probably be easiest to make the changes to fstab and then reboot. But if you made sure you weren't logged in as a normal user then
# umount /dev/sda3 # umount /dev/sdc1 # mount /dev/sda3 # mount /dev/sdc1
should work.
Without rebooting, one can just umount homes, change fstab, mount homes again. And doing it this way you test that fstab is correct. If not, it is a pain on reboot.
You seem to be agreeing with me now, since our disagreement is about whether you can change fstab whilst the affected filesystems are mounted. But you can't just umount /home, as Bob points out subsequently, if you're logged in as a normal user and thus with a home directory in /home since this means that /home is busy in that case and it can't be umounted. You need to be logged in as e.g root, not just use su or sudo. Which is exactly what I said. But/and there is no need to umount the filesystems first, you can leave them mounted whilst you edit fstab. The critical point is that you can't umount a busy filesystem; nothing to do with editing fstab.
The other critical moment is that you can not umount "/home.new" when the fstab entry for it has been removed, and that partition now is mounted on /home. "mount" will say it can not find it. -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
On Sun, 20 Nov 2022 13:18:32 +0100 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 2022-11-20 02:24, Dave Howorth wrote:
On Sat, 19 Nov 2022 18:42:39 +0100 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 2022-11-19 16:09, Dave Howorth wrote:
On Sat, 19 Nov 2022 13:07:55 +0100 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 2022-11-19 12:51, Dave Howorth wrote:
On Sat, 19 Nov 2022 12:19:38 +0100 "Carlos E. R." <robin.listas@telefonica.net> wrote:
> On 2022-11-19 06:13, Bob Rogers wrote: >> From: "Carlos E. R." <robin.listas@telefonica.net> >> Date: Fri, 18 Nov 2022 18:45:45 +0100 (CET) >> >> On Friday, 2022-11-18 at 10:04 -0500, Mark Misulich >> wrote: >> > Hi, >> > I recently bought a 1TB hard drive to add in to my >> > computer. My drives will be dev/sda, a SSD which >> > presently contains Leap 15.4 / and /home. dev/sdb is >> > a standard drive, which contains Win 10 and Win XP. >> > The third drive will be /dev/sdc, which will be the >> > new 1TB drive . . . >> >> . . . >> >> > #cp /etc/fstab /etc/fstab.org >> > #gedit /etc/fstab >> >> No, do it earlier. >> >> To refine what Carlos said, it makes life easier if you add a >> line in /etc/fstab for the new /home partition earlier, >> as /home.new, so it looks something like this: >> >> /dev/sda3 /home ext4 defaults 0 0 >> /dev/sdc1 /home.new ext4 defaults 0 0 >> >> Then after you move the data, you can edit /etc/fstab again to >> change /home to /home.old (creating the mount point of course) >> and /home.new to /home and simply reboot. No explicit mounts >> or unmounts required, and you don't even need to log out as >> you until then. > > Remember that you have to change fstab with affected partitions > not mounted.
Eh, why? I've never done that. AFAIK you can edit fstab whenever you like. Nothing looks at it until you execute some command that uses it.
If you have
/dev/sda3 /home ext4 defaults 0 0 /dev/sdc1 /home.new ext4 defaults 0 0
and change to:
/dev/sda3 /home.old ext4 defaults 0 0 /dev/sdc1 /home ext4 defaults 0 0
You have problems when trying to mount the second version.
I don't see why. In this case, since you're changing /home it'll probably be easiest to make the changes to fstab and then reboot. But if you made sure you weren't logged in as a normal user then
# umount /dev/sda3 # umount /dev/sdc1 # mount /dev/sda3 # mount /dev/sdc1
should work.
Without rebooting, one can just umount homes, change fstab, mount homes again. And doing it this way you test that fstab is correct. If not, it is a pain on reboot.
You seem to be agreeing with me now, since our disagreement is about whether you can change fstab whilst the affected filesystems are mounted. But you can't just umount /home, as Bob points out subsequently, if you're logged in as a normal user and thus with a home directory in /home since this means that /home is busy in that case and it can't be umounted. You need to be logged in as e.g root, not just use su or sudo. Which is exactly what I said. But/and there is no need to umount the filesystems first, you can leave them mounted whilst you edit fstab. The critical point is that you can't umount a busy filesystem; nothing to do with editing fstab.
The other critical moment is that you can not umount "/home.new" when the fstab entry for it has been removed, and that partition now is mounted on /home. "mount" will say it can not find it.
Did I mention /home.new anywhere? Did I suggest remounting any filesystem before unmounting all of those involved? So the 'critical moment' you speak of does not exist.
On 2022-11-20 17:35, Dave Howorth wrote:
On Sun, 20 Nov 2022 13:18:32 +0100 "Carlos E. R." <> wrote:
On 2022-11-20 02:24, Dave Howorth wrote:
On Sat, 19 Nov 2022 18:42:39 +0100 "Carlos E. R." <> wrote:
On 2022-11-19 16:09, Dave Howorth wrote:
On Sat, 19 Nov 2022 13:07:55 +0100 "Carlos E. R." <> wrote:
On 2022-11-19 12:51, Dave Howorth wrote: > On Sat, 19 Nov 2022 12:19:38 +0100 > "Carlos E. R." <> wrote: > >> On 2022-11-19 06:13, Bob Rogers wrote: >>> From: "Carlos E. R." <> >>> Date: Fri, 18 Nov 2022 18:45:45 +0100 (CET) >>> >>> On Friday, 2022-11-18 at 10:04 -0500, Mark Misulich >>> wrote: >>> > Hi, >>> > I recently bought a 1TB hard drive to add in to my >>> > computer. My drives will be dev/sda, a SSD which >>> > presently contains Leap 15.4 / and /home. dev/sdb is >>> > a standard drive, which contains Win 10 and Win XP. >>> > The third drive will be /dev/sdc, which will be the >>> > new 1TB drive . . . >>> >>> . . . >>> >>> > #cp /etc/fstab /etc/fstab.org >>> > #gedit /etc/fstab >>> >>> No, do it earlier. >>> >>> To refine what Carlos said, it makes life easier if you add a >>> line in /etc/fstab for the new /home partition earlier, >>> as /home.new, so it looks something like this: >>> >>> /dev/sda3 /home ext4 defaults 0 0 >>> /dev/sdc1 /home.new ext4 defaults 0 0 >>> >>> Then after you move the data, you can edit /etc/fstab again to >>> change /home to /home.old (creating the mount point of course) >>> and /home.new to /home and simply reboot. No explicit mounts >>> or unmounts required, and you don't even need to log out as >>> you until then. >> >> Remember that you have to change fstab with affected partitions >> not mounted. > > Eh, why? I've never done that. AFAIK you can edit fstab whenever > you like. Nothing looks at it until you execute some command > that uses it.
If you have
/dev/sda3 /home ext4 defaults 0 0 /dev/sdc1 /home.new ext4 defaults 0 0
and change to:
/dev/sda3 /home.old ext4 defaults 0 0 /dev/sdc1 /home ext4 defaults 0 0
You have problems when trying to mount the second version.
I don't see why. In this case, since you're changing /home it'll probably be easiest to make the changes to fstab and then reboot. But if you made sure you weren't logged in as a normal user then
# umount /dev/sda3 # umount /dev/sdc1 # mount /dev/sda3 # mount /dev/sdc1
should work.
Without rebooting, one can just umount homes, change fstab, mount homes again. And doing it this way you test that fstab is correct. If not, it is a pain on reboot.
You seem to be agreeing with me now, since our disagreement is about whether you can change fstab whilst the affected filesystems are mounted. But you can't just umount /home, as Bob points out subsequently, if you're logged in as a normal user and thus with a home directory in /home since this means that /home is busy in that case and it can't be umounted. You need to be logged in as e.g root, not just use su or sudo. Which is exactly what I said. But/and there is no need to umount the filesystems first, you can leave them mounted whilst you edit fstab. The critical point is that you can't umount a busy filesystem; nothing to do with editing fstab.
The other critical moment is that you can not umount "/home.new" when the fstab entry for it has been removed, and that partition now is mounted on /home. "mount" will say it can not find it.
Did I mention /home.new anywhere? Did I suggest remounting any > filesystem before unmounting all of those involved? So the 'critical moment' you speak of does not exist.
*We* did. -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
* Carlos E. R. <robin.listas@telefonica.net> [11-20-22 13:05]:
On 2022-11-20 17:35, Dave Howorth wrote:
On Sun, 20 Nov 2022 13:18:32 +0100 "Carlos E. R." <> wrote:
On 2022-11-20 02:24, Dave Howorth wrote:
On Sat, 19 Nov 2022 18:42:39 +0100 "Carlos E. R." <> wrote:
On 2022-11-19 16:09, Dave Howorth wrote:
On Sat, 19 Nov 2022 13:07:55 +0100 "Carlos E. R." <> wrote: > On 2022-11-19 12:51, Dave Howorth wrote: > > On Sat, 19 Nov 2022 12:19:38 +0100 > > "Carlos E. R." <> wrote: > > > On 2022-11-19 06:13, Bob Rogers wrote: > > > > From: "Carlos E. R." <> > > > > Date: Fri, 18 Nov 2022 18:45:45 +0100 (CET) > > > > > > > > On Friday, 2022-11-18 at 10:04 -0500, Mark Misulich > > > > wrote: > > > > > Hi, > > > > > I recently bought a 1TB hard drive to add in to my > > > > > computer. My drives will be dev/sda, a SSD which > > > > > presently contains Leap 15.4 / and /home. dev/sdb is > > > > > a standard drive, which contains Win 10 and Win XP. > > > > > The third drive will be /dev/sdc, which will be the > > > > > new 1TB drive . . . > > > > > > > > . . . > > > > > #cp /etc/fstab /etc/fstab.org > > > > > #gedit /etc/fstab > > > > > > > > No, do it earlier. > > > > > > > > To refine what Carlos said, it makes life easier if you add a > > > > line in /etc/fstab for the new /home partition earlier, > > > > as /home.new, so it looks something like this: > > > > > > > > /dev/sda3 /home ext4 defaults 0 0 > > > > /dev/sdc1 /home.new ext4 defaults 0 0 > > > > > > > > Then after you move the data, you can edit /etc/fstab again to > > > > change /home to /home.old (creating the mount point of course) > > > > and /home.new to /home and simply reboot. No explicit mounts > > > > or unmounts required, and you don't even need to log out as > > > > you until then. > > > > > > Remember that you have to change fstab with affected partitions > > > not mounted. > > > > Eh, why? I've never done that. AFAIK you can edit fstab whenever > > you like. Nothing looks at it until you execute some command > > that uses it. > > If you have > > /dev/sda3 /home ext4 defaults 0 0 > /dev/sdc1 /home.new ext4 defaults 0 0 > > and change to: > > /dev/sda3 /home.old ext4 defaults 0 0 > /dev/sdc1 /home ext4 defaults 0 0 > > You have problems when trying to mount the second version.
I don't see why. In this case, since you're changing /home it'll probably be easiest to make the changes to fstab and then reboot. But if you made sure you weren't logged in as a normal user then
# umount /dev/sda3 # umount /dev/sdc1 # mount /dev/sda3 # mount /dev/sdc1
should work.
Without rebooting, one can just umount homes, change fstab, mount homes again. And doing it this way you test that fstab is correct. If not, it is a pain on reboot.
You seem to be agreeing with me now, since our disagreement is about whether you can change fstab whilst the affected filesystems are mounted. But you can't just umount /home, as Bob points out subsequently, if you're logged in as a normal user and thus with a home directory in /home since this means that /home is busy in that case and it can't be umounted. You need to be logged in as e.g root, not just use su or sudo. Which is exactly what I said. But/and there is no need to umount the filesystems first, you can leave them mounted whilst you edit fstab. The critical point is that you can't umount a busy filesystem; nothing to do with editing fstab.
The other critical moment is that you can not umount "/home.new" when the fstab entry for it has been removed, and that partition now is mounted on /home. "mount" will say it can not find it.
Did I mention /home.new anywhere? Did I suggest remounting any > filesystem before unmounting all of those involved? So the 'critical moment' you speak of does not exist.
*We* did.
-- Cheers / Saludos,
Carlos E. R. (from 15.3 x86_64 at Telcontar)
<public admonishmont> IF, ya'll are done ranting, consider trimming many quotes with nothing to do with the ranting at each other. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc
Patrick Shanahan composed on 2022-11-20 13:14 (UTC-0500): ...
<public admonishmont> IF, ya'll are done ranting, consider trimming many quotes with nothing to do with the ranting at each other.
Great example you are, adding another 109 useless quote lines in the archives for the search bots to weed through. :p -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
From: "Carlos E. R." <robin.listas@telefonica.net> Date: Sat, 19 Nov 2022 12:19:38 +0100 On 2022-11-19 06:13, Bob Rogers wrote:
From: "Carlos E. R." <robin.listas@telefonica.net> Date: Fri, 18 Nov 2022 18:45:45 +0100 (CET)
. . .
And instead of rsync, I would recommend doing the copy by making a backup on /home.old, verifying it there, restoring it on /home.new, and verifying it there as well (which also proves the backup is good).
Doing a backup, how? Because I do backups with resync precisely the way I posted :-) True, that is another valid method of doing backups. I prefer to use dar for archival backups [1] so I can recover from accidental deletion or corruption weeks or years after the fact. And I assumed Mark had something of the sort in place for his original /home partition, so that would be an easy way of doing the copy. ================ From: "Carlos E. R." <robin.listas@telefonica.net> Date: Sat, 19 Nov 2022 18:42:39 +0100 On 2022-11-19 16:09, Dave Howorth wrote:
. . .
I don't see why. In this case, since you're changing /home it'll probably be easiest to make the changes to fstab and then reboot. But if you made sure you weren't logged in as a normal user then
# umount /dev/sda3 # umount /dev/sdc1 # mount /dev/sda3 # mount /dev/sdc1
should work.
Without rebooting, one can just umount homes, change fstab, mount homes again. And doing it this way you test that fstab is correct. If not, it is a pain on reboot. -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar) Also true, having experienced such pain myself. But I've also seen many cases where umount fails because it thinks the partition is in use, despite all my efforts to the contrary. Admittedly, this was only for partitions exported via Samba and NFS, so may not apply in Mark's case. And trying the explicit umount first would be safer. -- Bob [1] http://www.rgrjr.com/linux/backup.html
On 2022-11-20 01:25, Bob Rogers wrote:
From: "Carlos E. R." <> Date: Sat, 19 Nov 2022 12:19:38 +0100
On 2022-11-19 06:13, Bob Rogers wrote: > From: "Carlos E. R." <> > Date: Fri, 18 Nov 2022 18:45:45 +0100 (CET) > > . . . > > And instead of rsync, I would recommend doing the copy by making a > backup on /home.old, verifying it there, restoring it on /home.new, > and verifying it there as well (which also proves the backup is > good).
Doing a backup, how?
Because I do backups with resync precisely the way I posted :-)
True, that is another valid method of doing backups. I prefer to use dar for archival backups [1] so I can recover from accidental deletion or corruption weeks or years after the fact. And I assumed Mark had something of the sort in place for his original /home partition, so that would be an easy way of doing the copy.
I do backups with rsync to an external hard disk, encrypted and with compression, using btrfs which is the only filesystem I know in Linux capable of doing compression on the fly. Then I remove the hard disk. I can have several dated directories with copies done on different dates, using rsync capability to create hard links to files that did not change, thus reducing further the disk space used. There ready made scripts for the purpose, but I do my own. -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
From: "Carlos E. R." <robin.listas@telefonica.net> Date: Sun, 20 Nov 2022 01:34:12 +0100 I do backups with rsync to an external hard disk, encrypted and with compression, using btrfs which is the only filesystem I know in Linux capable of doing compression on the fly. Then I remove the hard disk. I can have several dated directories with copies done on different dates, using rsync capability to create hard links to files that did not change, thus reducing further the disk space used. There ready made scripts for the purpose, but I do my own. -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar) I assume you are referring to the --link-dest option? That's pretty cool; I did not know rsync could do that. Between btrfs compression and --link-dest, you should be able to make incremental backups more or less equivalent to what dar or tar can do. But I wonder how easy they would be to move to other media with all those hard links. I also copy backups from my server to my desktop system and periodically write the long-term backups to DVD. The whole create/verify/copy process and much of the work of purging old backups is done automatically, so I only have to step in to burn a DVD once every month or two. -- Bob
On 2022-11-20 03:24, Bob Rogers wrote:
From: "Carlos E. R." <robin.listas@telefonica.net> Date: Sun, 20 Nov 2022 01:34:12 +0100
I do backups with rsync to an external hard disk, encrypted and with compression, using btrfs which is the only filesystem I know in Linux capable of doing compression on the fly. Then I remove the hard disk.
I can have several dated directories with copies done on different dates, using rsync capability to create hard links to files that did not change, thus reducing further the disk space used.
There ready made scripts for the purpose, but I do my own.
I assume you are referring to the --link-dest option? That's pretty cool; I did not know rsync could do that. Between btrfs compression and --link-dest, you should be able to make incremental backups more or less equivalent to what dar or tar can do.
Yes, that's the idea.
But I wonder how easy they would be to move to other media with all those hard links. I also copy backups from my server to my desktop system and periodically write the long-term backups to DVD. The whole create/verify/copy process and much of the work of purging old backups is done automatically, so I only have to step in to burn a DVD once every month or two.
You copy the files normally, with any tool. cp, file browser, whatever. You just choose (navigate) to the folder that contains the version (date) of the backup you want. -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
From: "Carlos E. R." <robin.listas@telefonica.net> Date: Sun, 20 Nov 2022 13:22:07 +0100 On 2022-11-20 03:24, Bob Rogers wrote:
. . .
But I wonder how easy they would be to move to other media with all those hard links. I also copy backups from my server to my desktop system and periodically write the long-term backups to DVD. The whole create/verify/copy process and much of the work of purging old backups is done automatically, so I only have to step in to burn a DVD once every month or two.
You copy the files normally, with any tool. cp, file browser, whatever. You just choose (navigate) to the folder that contains the version (date) of the backup you want. -- Cheers / Saludos, Carlos E. R. What I meant was this: You can't copy those folders individually as incremental backups. Unless I am missing something, copying one of them to a new partition restores all data as of the backup date; it's a "full restore." Unless you copy the whole backup tree, copying cannot preserve all of the hard links, which loses the "incremental backup" effect. In particular, if I were to adopt your system, I would lose the option of writing weekly incremental dumps to DVD. The tradeoff between rsync and the more traditional dump/tar/dar style of backup has moved, but there's still a tradeoff. -- Bob
On 2022-11-21 21:59, Bob Rogers wrote:
From: "Carlos E. R." <robin.listas@telefonica.net> Date: Sun, 20 Nov 2022 13:22:07 +0100
On 2022-11-20 03:24, Bob Rogers wrote:
> . . . > > But I wonder how easy they would be to move to other media with > all those hard links. I also copy backups from my server to my > desktop system and periodically write the long-term backups to DVD. > The whole create/verify/copy process and much of the work of > purging old backups is done automatically, so I only have to step > in to burn a DVD once every month or two.
You copy the files normally, with any tool. cp, file browser, whatever. You just choose (navigate) to the folder that contains the version (date) of the backup you want.
What I meant was this: You can't copy those folders individually as incremental backups. Unless I am missing something, copying one of them to a new partition restores all data as of the backup date; it's a "full restore." Unless you copy the whole backup tree, copying cannot preserve all of the hard links, which loses the "incremental backup" effect.
You just copy one dated folder, the one you want to restore, which restores the status you had in the original that day. You simply ignore if a file is a file or a hardlink to a file, that is irrelevant to you. No, there is no simple way to find out what changed that day and copy only that. I would use a similar but reversed rsync command as the one used to do the backup.
In particular, if I were to adopt your system, I would lose the option of writing weekly incremental dumps to DVD. The tradeoff between rsync and the more traditional dump/tar/dar style of backup has moved, but there's still a tradeoff.
No, with rsync and --link-dest you make backups to a different hard disk, normally an external one that you keep unplugged and safe. Not to DVDs. You can, of course, also copy one dated folder to a DVD if you wish. but it is a different strategy. I simply do not use DVDs because it can hold just a tiny bit of my data. I can use Blue Ray disks, which I do use for archival of data, such as photos. But the procedure is very tedious for routine backups. -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
Le 21/11/2022 à 22:13, Carlos E. R. a écrit :
No, there is no simple way to find out what changed that day and copy only that.
sort by date? jdd -- mon serveur usenet: dodin.fr.nf c'est quoi, usenet? http://www.dodin.org/wiki/pmwiki.php?n=Usenet.Usenet
On 2022-11-21 22:42, jdd@dodin.org wrote:
Le 21/11/2022 à 22:13, Carlos E. R. a écrit :
No, there is no simple way to find out what changed that day and copy only that.
sort by date? By modification date, yes. Take those files in a bracket of dates.
-- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
From: "Carlos E. R." <robin.listas@telefonica.net> Date: Mon, 21 Nov 2022 22:13:29 +0100 On 2022-11-21 21:59, Bob Rogers wrote:
What I meant was this: You can't copy those folders individually as incremental backups. Unless I am missing something, copying one of them to a new partition restores all data as of the backup date; it's a "full restore." Unless you copy the whole backup tree, copying cannot preserve all of the hard links, which loses the "incremental backup" effect.
. . . I simply do not use DVDs because it can hold just a tiny bit of my data. That's exactly my point: You can't use smaller media because your incrementals have to live on the same volume as the full dumps, which limits the amount of archival data you can keep. ================ From: "Carlos E. R." <robin.listas@telefonica.net> Date: Mon, 21 Nov 2022 23:20:13 +0100 On 2022-11-21 22:42, jdd@dodin.org wrote:
Le 21/11/2022 à 22:13, Carlos E. R. a écrit :
No, there is no simple way to find out what changed that day and copy only that.
sort by date?
By modification date, yes. Take those files in a bracket of dates. -- Cheers / Saludos, Carlos E. R. Using "find -mtime" also works. -- Bob
On 2022-11-21 23:39, Bob Rogers wrote:
From: "Carlos E. R." <robin.listas@telefonica.net> Date: Mon, 21 Nov 2022 22:13:29 +0100
On 2022-11-21 21:59, Bob Rogers wrote:
> What I meant was this: You can't copy those folders individually > as incremental backups. Unless I am missing something, copying one > of them to a new partition restores all data as of the backup date; > it's a "full restore." Unless you copy the whole backup tree, > copying cannot preserve all of the hard links, which loses the > "incremental backup" effect.
. . .
I simply do not use DVDs because it can hold just a tiny bit of my data.
That's exactly my point: You can't use smaller media because your incrementals have to live on the same volume as the full dumps, which limits the amount of archival data you can keep.
I have to keep the first backup in any case, which is about 500 GB, so once I have started with a hard disk, it is far easier to continue with that same hard disk. Just a single disk for the entire set, not a hundred DVDs. -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
From: "Carlos E. R." <robin.listas@telefonica.net> Date: Tue, 22 Nov 2022 02:36:14 +0100 On 2022-11-21 23:39, Bob Rogers wrote:
That's exactly my point: You can't use smaller media because your incrementals have to live on the same volume as the full dumps, which limits the amount of archival data you can keep.
I have to keep the first backup in any case, which is about 500 GB, so once I have started with a hard disk, it is far easier to continue with that same hard disk. Just a single disk for the entire set, not a hundred DVDs. -- Cheers / Saludos, Carlos E. R. I put them on HDD for starters, and only copy the full dumps and weekly incrementals (which include everything since the last full dump) to DVD, so the situation is not quite that drastic. I find I've been averaging 5 DVDs a year for the last five years. To be fair, this is the same system I originally developed for use at home and then expanded for the biotech startup where I used to work. There, indefinite archival was a hard requirement, and using external hard drives would have been a non-starter, having seen lots of hard drives fail. I've also had people come to me desperately looking for files that were 8-10 years old. So I'm using a system that is more robust and/or paranoid than I really need for home use, because it gives me lots of history, not to mention that warm fuzzy feeling. -- Bob
On Fri, 2022-11-18 at 18:45 +0100, Carlos E. R. wrote:
On Friday, 2022-11-18 at 10:04 -0500, Mark Misulich wrote:
Hi, I recently bought a 1TB hard drive to add in to my computer. My drives will be dev/sda, a SSD which presently contains Leap 15.4 / and /home. dev/sdb is a standard drive, which contains Win 10 and Win XP. The third drive will be /dev/sdc, which will be the new 1TB drive.
I want to move the Leap 15.4 /home from the SSD drive (dev/sda) to the 1TB drive (dev/sdc). I think the way to do this is as follows, but I'm asking the list to check this out to make sure I've got it correct.
#fdisk -l (to identify the disks and make sure I've got the correct discs planned out)
lsblk --output NAME,KNAME,RA,RM,RO,PARTFLAGS,SIZE,TYPE,FSTYPE,LABEL,PARTLABEL,PTTYPE ,MOUNTPOINT,UUID,PARTUUID,WWN,MODEL,ALIGNMENT | less -S
Gives a very complete information.
Then I will create a partition on /dev/sdc and format it.
#mount /dev/sdc1 /mnt (Once I've made and formatted the partition on the new drive, I will need to mount it.)
#cd /mnt (to see if I can change directories to the new filesystem)
#ls -ahl (to see what is in the new filesystem)
#rm -rf lost+found (remove the lost+found directory)
No.
#cp -rp /home/* /mnt (copy the home directory to the new filesystem on the new harddrive)
rsync --archive --acls --xattrs --hard-links --sparse --stats -- human-readable --one-file-system \ /home /mnt
Do it twice.
The second time, do it in text mode, in tty1, and make sure to log out of the GUI. And add a "--del", very carefully.
Actually, you could do an "init 3" before the second time.
Why twice? Because it takes very long, hours, and during the first time you can be using your computer.
#ls (to find out that everything is copied)
Use mc, compare directory sizes.
#mv /home /home.orig (rename old home directory)
I've gotten down to this point in the process that I detailed in my original post, and I've cut the subsequent text for clarity. When I run the command #mv /home /home.orig I get the response mv: cannot move '/home' to 'home.orig' : Device or resource busy I get this in both tty1 as root and graphical mode using konsole as root. I need some instruction to get around this problem. Thanks, Mark
* Mark Misulich <munguanaweza@gmail.com> [11-21-22 11:23]: ...
I've gotten down to this point in the process that I detailed in my original post, and I've cut the subsequent text for clarity. When I run the command
#mv /home /home.orig
I get the response
mv: cannot move '/home' to 'home.orig' : Device or resource busy
I get this in both tty1 as root and graphical mode using konsole as root. I need some instruction to get around this problem.
<user> owning /home is logged in. you need to drop to runlevel 1, whatever it is called now and then the directory will not be in use. or use cp or rsync or such -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc
On 21.11.2022 19:22, Mark Misulich wrote:
#mv /home /home.orig
I get the response
mv: cannot move '/home' to 'home.orig' : Device or resource busy
I get this in both tty1 as root and graphical mode using konsole as root. I need some instruction to get around this problem.
You need to unmount /home first.
On 2022-11-21 17:22, Mark Misulich wrote:
On Fri, 2022-11-18 at 18:45 +0100, Carlos E. R. wrote:
On Friday, 2022-11-18 at 10:04 -0500, Mark Misulich wrote:
Hi, I recently bought a 1TB hard drive to add in to my computer. My drives
...
#mv /home /home.orig (rename old home directory)
I've gotten down to this point in the process that I detailed in my original post, and I've cut the subsequent text for clarity. When I run the command
#mv /home /home.orig
I get the response
mv: cannot move '/home' to 'home.orig' : Device or resource busy
It is still mounted.
I get this in both tty1 as root and graphical mode using konsole as root. I need some instruction to get around this problem.
I mentioned that you should switch to runlevel 3, and log in terminal 1 as root. Then : umount -v /home If it fails saying it is busy, then lsof /home and kill those processes one by one. Or, switch to runlevel 1. -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
On Tuesday, 22 November 2022 4:38:15 AM ACDT Carlos E. R. wrote:
[...] I mentioned that you should switch to runlevel 3, and log in terminal 1 as root. Then :
umount -v /home
If it fails saying it is busy, then
lsof /home
and kill those processes one by one.
Or, switch to runlevel 1.
These days that is accomplished by "systemctl isolate rescue.target". Regards, Rodney. -- ================================================================================================================== Rodney Baker rodney.baker@iinet.net.au ==================================================================================================================
On 2022-11-21 23:20, Rodney Baker wrote:
On Tuesday, 22 November 2022 4:38:15 AM ACDT Carlos E. R. wrote:
[...] I mentioned that you should switch to runlevel 3, and log in terminal 1 as root. Then :
umount -v /home
If it fails saying it is busy, then
lsof /home
and kill those processes one by one.
Or, switch to runlevel 1.
These days that is accomplished by "systemctl isolate rescue.target".
And you think we are going to remember that? :-D Fortunately, "init 1" is not going out anytime soon. -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
On Tuesday, 22 November 2022 12:03:08 PM ACDT Carlos E. R. wrote:
On 2022-11-21 23:20, Rodney Baker wrote:
On Tuesday, 22 November 2022 4:38:15 AM ACDT Carlos E. R. wrote:
[...] I mentioned that you should switch to runlevel 3, and log in terminal 1 as root. Then :
umount -v /home
If it fails saying it is busy, then
lsof /home
and kill those processes one by one.
Or, switch to runlevel 1.
These days that is accomplished by "systemctl isolate rescue.target".
And you think we are going to remember that? :-D
Fortunately, "init 1" is not going out anytime soon.
LOL. :) I didn't think I ever would either (and yes, it seems like a case of pointless exttra typing). The hardest bit to remember is the names of the targets. Thankfully the only 3 I've ever needed are "rescue" (i.e. Single-user mode), "multi-user" (text only, no gui, kills X/Wayland), and "graphical". Init [1,3,5] was much easier, except that runlevel numbers were not necessarily the same across all distros whereas systemd target names are (but we're digressing from the original subject now, so I'd better shut up). :) -- ================================================================================================================== Rodney Baker rodney.baker@iinet.net.au ==================================================================================================================
participants (9)
-
Andrei Borzenkov -
Bob Rogers -
Carlos E. R. -
Dave Howorth -
Felix Miata -
jdd＠dodin.org -
Mark Misulich -
Patrick Shanahan -
Rodney Baker