On 1/17/24 20:20, gene heskett wrote:
On 1/17/24 19:58, David Christensen wrote:On 1/17/24 15:58, gene heskett wrote:Now the question is how did it make this: homevol s/b very close to /home in size but:root@coyote:~# df && free Filesystem 1K-blocks Used Available Use% Mounted on udev 16327704 0 16327704 0% /dev tmpfs 3272684 1912 3270772 1% /run /dev/sda1 863983352 22348472 797673232 3% / tmpfs 16363420 1244 16362176 1% /dev/shm tmpfs 5120 8 5112 1% /run/lock /dev/sda3 47749868 784 45291076 1% /tmp /dev/md0p1 1796382580 335102676 1369954928 20% /home tmpfs 3272684 4956 3267728 1% /run/user/1000 /dev/sdh1 1967892164 354519236 1513336680 19% /mnt/homevoltotal used free shared buff/cache available Mem: 32726840 3417576 515520 934540 30072184 29309264Swap: 111902712 2048 111900664 root@coyote:~#It somehow changed 335G into 354G. Thinking the AppImages dir is full of soft links of short names pointing at the long filename and had turned the links into duplicates, that was the first thing I checked, but it was all good soft-links, so where did the extra 19.4G's come from? Can filesystem ext4's overhead account for that?I suggest running rsync(1) with --dry-run, --log-file=FILE, --itemize_changes, and whatever other options are needed to find the differences. Please RTFM rsync(1) to choose your options. These look useful:--archive, -a (-rlptgoD) --deleteWhy --delete?
If you have files on the destination from a previous run of rsync(1) and they no longer exist on the source, --delete will get rid of extraneous files on the destination.
--hard-links, -H --one-file-system, -x --sparse, -Sor --sparse?
First, you need to understand what "sparse file" means: https://en.wikipedia.org/wiki/Sparse_fileIf you have sparse files on the source -- say, 10 GB virtual machine images -- then you want rsync(1) to create sparse files on the destination.
Well, my abundance of curiosity, may have killed the cat, but if I understand how rsync's -a works, re-running the same command will only update for the incoming email and any posts I've made while it was running the first time. So the same command quoted last is now running again. when it has exited, which it has now done in about 15 minutes I'll edit fstab to remove the 60 gigs of swap on md1, remove the existing mount of md0p1 as /home taking the raid10 completely out of the system. And add the mounting of LABEL=homevolsdh1 as the /home partition and reboot. In the event I have to re-install, the raid will still contain my data and can be recovered. I already have a dvd with the most recent netinstall burnt. All I have to do is convince it to not install orca and brltty. Probably by unplugging _all_ usb stuff except the keyboard and mouse buttons.What would solve many of my problems is a bit of help from someone who it running trinity to tell me how to install it on a system w/o any installed gui which obviously disables synaptic. That leaves apt, apt-get, and aptitude, unless there is a better way. aptitude is uncontrollable, has fixed me once, has torn the system down to another install 3 times so the odds are not in my favor.So those fstab edits have been done, next is a reboot
You should be able to migrate your /home file system from RAID10 to an SSD without needing to reinstall Debian.
Copying a file system that is mounted read-write is problematic. It is best to remount it read-only, and then copy. This is hard to do when you are logged in and using the file system you want to copy. Options include rebooting into single-user root console or using live media.
To make an exact copy of the source, consider using a tool designed for this task -- such as cpio(1), tar(1), or a backup/restore system such as amanda(8).
If you use rsync(1), I suggest using some kind of integrity checking tool to verify that the source and destination file systems are identical. I prefer BSD mtree(8):
https://manpages.debian.org/bullseye/mtree-netbsd/mtree.8.en.html (Be careful not to confuse the above with mtree(5) via libarchive.) David