On Mon 09 Dec 2024 at 21:25:59 (-0800), Charlie Gibbs wrote: > On Mon Dec 9 20:53:54 2024 David Wright wrote: > > On Mon 09 Dec 2024 at 15:23:18 (-0800), Charlie Gibbs wrote: > > > >> Some of you may recall my account of trying to install a new disk (in > >> my case a 1TB NVMe stick) for use as a boot device. There has been > >> another thread or two from other people dealing with the same issue, > >> so it seems to be a hot topic. > >> > >> I'm still unwilling to give up all my installed packages and > >> customizations and rebuild the system from scratch, when all I want > >> to do is copy existing directories to a new boot drive. My own data > >> files all live in /home, a separate partition - no problem there. > >> But many binaries have been installed in places like /usr/bin; their > >> configuration files may or may not be in /home, but I'd rather not > >> lose them wherever they are. > > > > Why "But …"? Aren't most binaries (those that users run, anyway) > > installed in /usr/bin/. > > Yes - and since I have a copy of the old /usr/bin, I should be able > to retain them by simply copying the old /usr over the new one, > rather than having to re-install them one by one.
You still haven't said what files cause you concern in /usr/bin/. All the files belonging to Debian's packages are going to be present, because you wrote: > >> At this point the old and new systems' root partitions should be > >> as alike as possible, aside from my own customizations. That implies you installed the same set of Debian packages as were present on the old disk. Right? But… On Mon 09 Dec 2024 at 17:34:08 (-0800), Charlie Gibbs wrote: > On Mon Dec 9 17:25:55 2024 John Hasler wrote: > > Do you mean that you have placed stuff not under control of the > > package management system in /usr/bin? > > No, I've been good about installing things the approved way, That implies that you haven't polluted /usr/bin/ with non-Debian binaries. Is that true? Then why should anything be missing from /usr/bin/? > e.g. > > apt install zip > > Yes, not even zip is present after an installation from scratch - > and apt puts it into /usr/bin. That's irrelevant: it's just part of Step 1. What worries me is whether anything was copied by Step 5's: > >> sudo rsync -av /bin /mnt/backup > >> sudo rsync -av /lib /mnt/backup > >> sudo rsync -av /lib64 /mnt/backup > >> sudo rsync -av /sbin /mnt/backup > >> sudo rsync -av /usr /mnt/backup That stuff is all Debian's, and everything should already have been present and correct after Step 1. Much of /etc and /var too. But /var/lib/ contains the state of the system, and I would worry that any difference in the state of the old disk's system is going to be forced onto the new one, even when it's not appropriate. > >> Here's the process I've been trying so far: > >> > >> 1. Do a network install on the new drive; to be really belt-and- > >> suspenders, make sure everything is completely updated: > >> sudo apt update > >> sudo apt upgrade > >> > >> 2. Re-boot from the original drive and update everything: > >> sudo apt update > >> sudo apt upgrade > >> At this point the old and new systems' root partitions should be > >> as alike as possible, aside from my own customizations. > >> 3. Mount the new drive's root partition somewhere that I can access > >> from the original drive: > >> sudo mount /dev/nvme0n1p2 /mnt/backup > >> > >> 4. Save the new system's /etc/fstab: > >> sudo cp -p /mnt/backup/etc/fstab ~ > >> > >> 5. Copy directories from the original drive to the new drive: > >> sudo rsync -av /bin /mnt/backup > >> sudo rsync -av /etc /mnt/backup > >> sudo rsync -av /lib /mnt/backup > >> sudo rsync -av /lib64 /mnt/backup > >> sudo rsync -av /opt /mnt/backup > >> sudo rsync -av /sbin /mnt/backup > >> sudo rsync -av /usr /mnt/backup > >> sudo rsync -av /var /mnt/backup > >> sudo rsync -av /home /mnt/backup > >> [ … … ] > > I've never used DMs and DEs. Do they squirrel away anything > > with ownerships attached (either by name or number) that might > > be mistranslated, seeing as your two disks likely have different > > ideas on the matter. Others have expressed that better, with talk of attributes and ACLs. Cheers, David.
