Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #275450 > unrolled thread

Subject: Re: Adding a new boot disk while keeping old disk

Back to article view | Back to linux.debian.user

Contents

  Subject: Re: Adding a new boot disk while keeping old disk Charlie Gibbs <cgibbs@surfnaked.ca> - 2024-12-10 06:50 +0100
    Re: Subject: Re: Adding a new boot disk while keeping old disk David Wright <deblis@lionunicorn.co.uk> - 2024-12-10 18:10 +0100

#275450 — Subject: Re: Adding a new boot disk while keeping old disk

[Sorry about breaking the thread structure - I read this group
via Usenet and e-mail replies.]

On Mon Dec  9 20:53:54 2024 David Wright <deblis@lionunicorn.co.uk> 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.

 >> 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.

Good point.  I'll check out those files.

 >> 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.

Oops!  My bad.  That should be
     sudo cp -p ~/fstab /mnt/backup/etc
I'll try it again with the corrected command.

 >> 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.

I don't know, but it seems like a good place to look next.

Thanks for the hints.  I'll run some more tests tomorrow and
let you know the results.  Right now it's bedtime...

-- 
/~\  Charlie Gibbs                  |  You can't save the earth
\ /  <cgibbs@kltpzyxm.invalid>      |  unless you're willing to
  X   I'm really at ac.dekanfrus     |  make other people sacrifice.
/ \  if you read it the right way.  |    -- Dogbert the green consultant

[toc] | [next] | [standalone]

#275461

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.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web