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/.
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.
At that point, I would compare sorted versions of /etc/passwd
and /etc/group from both machines to make sure that they have
matching lists of user/group names. (The numeric IDs can be
different.) Otherwise rsync could mistranslate ownerships.
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
6. Restore the new drive's /etc/fstab:
sudo cp -p ~/etc/fstab /mnt/backup/etc
Where did that file come from? Not step 4.
7. Re-boot from the new drive and cross your fingers.
The system comes up with an xfce login window, but I can't log in
using my regular user ID. Sometimes the screen just goes black,
then after a couple of seconds re-displays a blank login screen.
Lately, though, I've been getting a window with the message:
Xsession: warning: unable to write to /tmp;
X session may exit with an error.
Clicking on "okay" makes the screen goes black; after a
couple of seconds it then returns to an empty login screen.
However, I can log in as root, which suggests some sort
of permissions issue, but it doesn't seem to be with /tmp:
drwxrwxrwt 12 root root 4096 Dec 9 11:58 tmp
To further muddy the waters, I can SSH in from another machine
using my regular user ID.
I'd like to resolve this, but if not I can always fall back to the
original drive. Anybody wanna buy a lightly used 1TB NVMe SSD?
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.
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.
At this point the old and new systems' root partitions should be
as alike as possible, aside from my own customizations.
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,
e.g.
apt install zip
Yes, not even zip is present after an installation from scratch -
and apt puts it into /usr/bin.
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
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.
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?
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.
I think it's time to throw in the towel. The only reason I'm spending
so much time on this is that I had knee surgery a few days ago and I'm sitting here at home, not mobile enough to do much else but putter with
my machines. But I think I'll just forget about that shiny new NVMe
SSD - it was an extra toy I got talked into as part of a motherboard
upgrade but it isn't really necessary. My original hard drive is still intact and works perfectly well (albeit a bit slower than the SSD),
so I'll just go back to booting from it. If someday my machine has
a meltdown and really does need to be rebuilt from scratch, then I'll re-visit the matter. It's sort of like normal system updates/upgrades - usually they work smoothly and I can upgrade from one release to another without touching anything else. But if things really go south (which
they have done once or twice in the past, but not often), I have enough backups to put Humpty Dumpty together again - and I'll work the SSD
into the re-build.
On Tue Dec 10 14:05:20 2024 David Wright <deblis@lionunicorn.co.uk> wrote:
You still haven't said what files cause you concern in /usr/bin/.
There are a lot of them, e.g. xscreensaver, zip, sox...
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?
Not quite. See below.
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.
No, it's not. Step 1 was just a basic network install.
I didn't ask for anything extra.
Digging around in some musty old files, I found some post-installation
notes left over from a previous upgrade. Here's an excerpt:
Most of that stuff goes into /usr/bin, but it's not put there
by a basic install from scratch. I have to do it manually.
And then there are the truly non-standard utilities like xv,
the Seamonkey web browser, and all my Steam games. I was
hoping to find ways to bring all that stuff over in an rsync
or two rather than rebuilding it piece by piece.
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.
Yes, I'm concerned that I'm overwriting parts of the new install
(e.g. in /etc and /var) that should be left alone; that's why I
was saving and restoring /etc/fstab, but there are probably other
things that I missed and one of them is no doubt what's biting me.
On the other tentacle, my Usenet archives are in /var/spool/slrnpull,
and I don't want to lose them.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 164:33:12 |
| Calls: | 10,385 |
| Calls today: | 2 |
| Files: | 14,057 |
| Messages: | 6,416,518 |