The Raspberry Pi Thread

I am going to read about it but this is the option I am talking about..

View attachment 107671
View attachment 107672

Use dietpi-drive_manager

1624390984249.png



You can assign a different physical drive to the same mountpoint e.g. /mnt/seagatehdd. Think of it that you have removed your old hard drive in your Windows PC which was mapped to D drive and then a new drive was attached to your PC which you now mapped to D.

You see I had first tested with a hard drive which I planned to replace with a SSD since I was planning to run this downloader from say morning 9 Am to 3 AM at night. So I had gone with a generic mountpoint name like /mnt/usb1 which denotes the first USB3 port on the Pi.
 
Wonder what is with Raspberry Pi 4 corrupting USB drives !! Have lost 2 sandisk ultra.
I'm planning to switch to SSD boot + root. Is something I need to take care of ?
 
I have a seagate 2TB HDD connected to my RPi which runs on DietPI. I may be getting a higher capacity hdd to use with it and I will need to sort of copy everything from the existing hdd to the new one.

I think there is a tool in DietPI to do this but I haven't tried. Anyone has experience doing this? Also my current hdd is mounted as

Code:
/mnt/seagatehdd/

I cannot have same mount on the new HDD right? Or I can? Please be aware that I intend to remove the existing seagate 2TB and use only the new HDD. Because if I can have same mount point then I don't have to go and modify all settings in sonarr, radarr, qbittorrent etc. It may not be a lot of work doing that but I prefer not to do.
If the issue still is relevant.

Yes, you can mount the new HDD under the exact same directory. You only need to make sure that the copied file tree structure is exactly the same as on the older HDD, for your programs to continue working.

To copy files to your new HDD, you may use rsync (as already suggested), or just a plain old "cp -af" command. Again, as suggested, getting to know rsync is a great idea if you frequently need to deal with backing up or mirroring data, especially over a network.
 
If the issue still is relevant.

Yes, you can mount the new HDD under the exact same directory. You only need to make sure that the copied file tree structure is exactly the same as on the older HDD, for your programs to continue working.

To copy files to your new HDD, you may use rsync (as already suggested), or just a plain old "cp -af" command. Again, as suggested, getting to know rsync is a great idea if you frequently need to deal with backing up or mirroring data, especially over a network.

The issue is still relevant since I am waiting for some discount on the 4TB/5TB External portable HDD and will buy it once I get that discount. I am in no hurry. I will try rsync but this is going to be a one time thing I feel so not sure if I really need to invest time in learning rsync and also yes directory structure on source and destination will be exactly same.
 
... I will try rsync but this is going to be a one time thing I feel so not sure if I really need to invest time in learning rsync and also yes directory structure on source and destination will be exactly same.
In this case, cp -af <source-mount-dir> <dest-mount-dir> should suffice. Roughly, you'll need to mount both drives and perform this copy (preferably as root/sudo, since -a preserves permissions) and you should be good.
 
The issue is still relevant since I am waiting for some discount on the 4TB/5TB External portable HDD and will buy it once I get that discount. I am in no hurry. I will try rsync but this is going to be a one time thing I feel so not sure if I really need to invest time in learning rsync and also yes directory structure on source and destination will be exactly same.
Its easy as heck man.

This code snippet is from my backup script which copies the dietpi-backup folder to another folder with timestamp appended to the end of the folder name. e.g. system_backup_20210630124351

TIMESTAMP=$(date +"%Y%m%d_%H%M%S")
USB_PATH=/mnt/usb1
rsync -r --progress "${USB_PATH}/dietpi-backup" "${USB_PATH}/system_backup_${TIMESTAMP}"
 
In this case, cp -af <source-mount-dir> <dest-mount-dir> should suffice. Roughly, you'll need to mount both drives and perform this copy (preferably as root/sudo, since -a preserves permissions) and you should be good.

My source is /mnt/seagatehdd and destination will be say /mnt/wdhdd but then once copy is done, can I change the name of /mnt/wdhdd to /mnt/seagatehdd ? Because otherwise, all my other stuff like sonarr, qbittorrent, Jellyfin etc won't work anymore if mount point name changes.
To elaborate, I have like this...

Code:
Mount target: /mnt/seagatehdd                                                                                      
Mount source: /dev/sda1                                                                                            
Filesystem:   ext4                                                                                                  
UUID:         7ebc8b21-8573-45b3-bc98-xxxxxxxxxxxx                                                                  
Allocation:   Capacity: 1.8TiB | Used: 1.7TiB (93%)                                                                
Status:       Drive is online and ready for use                                                                    
Read only:    Disabled

After I get new say 4TB drive, it should show up (after all copying and all) as...

Code:
Mount target: /mnt/seagatehdd                                                                                      
Mount source: /dev/sda1                                                                                            
Filesystem:   ext4                                                                                                  
UUID:         7ebc8b21-8573-45b3-yyyy-yyyyyyy                                                                  
Allocation:   Capacity: 3.63TiB | Used: x.xxiB (xx%)                                                                
Status:       Drive is online and ready for use                                                                    
Read only:    Disabled

The mount target has to be exactly same after I put the new HDD to use.
 
Last edited:
A bit of a fresher here (I am a programmer, but zero experience with raspi)
I want to set up a pi-hole (to eliminate all ads on devices within local network)
We are a family of 4 with 2 laptops, 2 PCs, 5-6 mobiles at the most active at once.

Which Raspberry Pi should I go with? Would the zero be enough or need something like 3B/4?
 
My source is /mnt/seagatehdd and destination will be say /mnt/wdhdd but then once copy is done, can I change the name of /mnt/wdhdd to /mnt/seagatehdd ? Because otherwise, all my other stuff like sonarr, qbittorrent, Jellyfin etc won't work anymore if mount point name changes.
To elaborate, I have like this...
Sure. You should change the name of the mount directory once the copy is finished.

Do take care to go about this very carefully and retain the permissions/ownership of the main mount directory (the sub-directories should be fine, since you use the -a flag). Assuming the working/existing mount directory is on /mnt/seagatehdd and the mount directory for the new drive is /mnt/wdhdd, one possible sequence of operations would be:

1. cp -af /mnt/seagatehdd /mnt/wdhdd/seagatehdd # Note that you are copying the source directory to a sub-directory inside the destination. This is to make sure you include dot files/directories.
2. umount /mnt/seagatehdd # Make sure you stop programs/services that use files from this tree, to get around "device busy" errors. After this, ls -a /mnt/seagatehdd should show empty.
3. rmdir /mnt/seagatehdd # Remove source directory
4. mv /mnt/wdhdd/seagatehdd/* /mnt/wdhdd and mv /mnt/wdhdd/seagatehdd/.* /mnt/wdhdd # Move regular and dot files separately. This is where a tool like rsync makes life so much easier.
5. umount /mnt/wdhdd # Unmount new drive
6. mount /dev/sda1 /mnt/seagatehdd # Remount new drive to original destination. Assuming block device for new drive to be /dev/sda1

You may also need to alter /etc/fstab to mount your replacement drive (in place of the older one) automatically on subsequent boots, in case the block device paths differ, or if UUID/PARTUUID is used. Please post your /etc/fstab should you need help here.

P.S. - Corrected issues from my original version. A (possibly more elegant) rsync version a few posts down.
 
Last edited:
  • Like
Reactions: raksrules
@codelad This is how /etc/fstab currently looks...

Code:
# You can use "dietpi-drive_manager" to setup mounts.
# NB: It overwrites and re-creates physical drive mount entries on use.
#----------------------------------------------------------------
# NETWORK
#----------------------------------------------------------------


#----------------------------------------------------------------
# TMPFS
#----------------------------------------------------------------
tmpfs /tmp tmpfs size=1938M,noatime,lazytime,nodev,nosuid,mode=1777
tmpfs /var/log tmpfs size=50M,noatime,lazytime,nodev,nosuid,mode=1777

#----------------------------------------------------------------
# MISC: ecryptfs, vboxsf (VirtualBox shared folder), gluster, bind mounts
#----------------------------------------------------------------


#----------------------------------------------------------------
# SWAP SPACE
#----------------------------------------------------------------


#----------------------------------------------------------------
# PHYSICAL DRIVES
#----------------------------------------------------------------
PARTUUID=9730496b-02 / ext4 noatime,lazytime,rw 0 1
PARTUUID=9730496b-01 /boot vfat noatime,lazytime,rw 0 2
UUID=7ebc8b21-8573-45b3-bc98-65fc7c837f14 /mnt/seagatehdd ext4 noatime,lazytime,rw,nofail,noauto,x-systemd.automount
 
@codelad This is how /etc/fstab currently looks...
Code:
...
UUID=7ebc8b21-8573-45b3-bc98-65fc7c837f14 /mnt/seagatehdd ext4 noatime,lazytime,rw,nofail,noauto,x-systemd.automount
You'll need to change the UUID in this line to use that of your new drive. To find UUID of your new drive partition, use:
Code:
blkid -s UUID <block-device>
For example, if the block device for your newly mounted partition is at /dev/sda1:
Code:
blkid -s UUID /dev/sda1
 
  • Like
Reactions: booo and raksrules
You can use scsi device name instead of uuid too. but they tend to change during reboots. third column in fstab is the file system. in this case ext4. but your usb could be formatted in fat32. so run mount command to find filesystem before editing fstab.
for example/boot is fat file system.
 
  • Like
Reactions: codelad
@raksrules - Tell you what. Looking back at my earlier post, I'm afraid I really fumbled around trying to get things done with cp. Way too ugly. Haven't actually used regular cp for such tasks in a long while. Here's a (hopefully more elegant) rsync version:

I assume here that your existing drive partition (source) is mounted at /mnt/seagate and the new drive partition (dest) at /mnt/wd.

1. Rsync to transfer files to new drive (the / after /mnt/seagate is vital here):
# rsync -av /mnt/seagate/ /mnt/wd/

2. Unmount source partition (again, you may need to stop services actively accessing this path to get around "device busy" errors):
# umount /mnt/seagate

3. Unmount dest partition:
# umount /mnt/wd

4. Re-mount dest partition in the original path (assuming block device /dev/sda1 for your new drive partition):
# mount /dev/sda1 /mnt/seagate
You can use scsi device name instead of uuid too. but they tend to change during reboots. third column in fstab is the file system. in this case ext4. but your usb could be formatted in fat32. so run mount command to find filesystem before editing fstab.
for example/boot is fat file system.
Quite true. Avoid block device names - UUIDs are safer. In certain other circumstances, using block device names can really hurt you. And blkid is one other way to identify the filesystem.
 
Is rsync already installed in Dietpi or I need to install that tool first?


Edit: Forgot to mention that I have a desktop environment also installed on my Pi which I can access using VNC in case that helps my case.
 
Last edited:
There's your problem. Use the original one for pi4
Ok. Just wondering what is rationale behind this.

Recommended requirement for the pi is 3A. https://www.raspberrypi.org/documentation/hardware/raspberrypi/power/README.md
The dash charger supplies 5V @ 4A which fulfills the need. So should not be an issue ... unless there is any component drawing more current, which would then fry the board. The flash drive doesn't seem to be drawing more power. And if they does then it is the pen drive issue.
 
You can use scsi device name instead of uuid too. but they tend to change during reboots. third column in fstab is the file system. in this case ext4. but your usb could be formatted in fat32. so run mount command to find filesystem before editing fstab.
for example/boot is fat file system.

I will be formatting the new drive as ext4 itself.