> Sent: Tuesday, December 03, 2024 at 3:52 AM
> From: "Andrew M.A. Cater" <amaca...@einval.com>
> To: debian-user@lists.debian.org
> Subject: Re: From SSD to NVME
>
> On Tue, Dec 03, 2024 at 02:55:07AM +0100, poc...@homemail.com wrote:
> >
> >
> > > It might be easier to produce a clean new install and then just rsync
> > > data from the SSD drive to the appropriate directories on the NVME.
> >
> > No it is better that everything comes over all at one time
> >
>
> As someone else has put it elsewhere in the thread: new laptop means
> new drivers, potentially moving from legacy MBR to UEFI ... easier in
> many ways to put a clean install of Debian on from new media to start
> with (also wiping out whatever was there before if it came preinstalled
> with Windows or whatever).
None to little of that is relevant. The "drivers" are part of the kernel, it is
not 1995 anymore.
I go from MBR to GPT to UEFI all the time.
Is it nice to think that debian still has the microsoft mindset?
A "clean" install is not really required on a modern linux system.
Linux is not microsoft windows.
When people state the above it really just shows they don't understand Linux.
>
> > >
> > > I'm fairly sure this was brought up just about at the end of last month.
> >
> > It depends upon if you created a partition table, partitions and
> > filesystems on the drive.
> >
> > I create the drive layout on the drive then rsync the old drive to the new
> > drive.
> > Then I fixup the PARTUUID in the /etc/fstab and boot loader.
> > If I am using Archlinux or my own custom build os I have a blank /etc/fstab
> > and /etc/hosts
> >
> There's more than one way to do it: if you absolutely know what partition
> sizes you want, maybe - LVM and one partition is a fairly sensible starting
> point because partitions will grow and shrink, for example.
Nonsense, using/building distributions and running Linux since 1995, partitions
don't grow and shrink.
They are static. That is an outdated concept.
I have "cloned" my last 15 installs from a USB drive to another drive. Starting
from an old image on a USB drive that I don't recall how old it is to a new
sdcard/HDD/SDD/NVME drive then updated using the package manager and never had
an issue. debian is the only distribution that I have used that has a problem
doing that.
I have on occasion installed from a package manager (not dpkg/apt) to a systemd
nspawn container then copied that to a new drive properly prepared of course.
Put the drive into a new machine and boot and done. It just works.
It is not rocket science nor brain surgery and it is not hard at all to do.
The only time it seems to be an issue is when using debian.
Using Archlinux for instance you can (and I have) use an install image years
old and simply do an update and you are done. It is all up to date. Rolling
releases is how it is done.
Knowing how Linux boots and works is a help. I don't know every concept behind
linux but I do know how to build a system from scratch (building all the
packages myself as in cross compiling from AMD64 to ARM) and then get it to
boot. Tedious but not really difficult/hard.
[alarm@alarm ~]$ ls -l /
lrwxrwxrwx 1 root root 7 Nov 25 19:15 bin -> usr/bin
drwxr-xr-x 3 root root 4096 Dec 31 1969 boot
drwxr-xr-x 17 root root 3980 Dec 2 10:38 dev
drwxr-xr-x 52 root root 4096 Dec 2 20:58 etc
drwxr-xr-x 3 root root 4096 Aug 19 03:43 home
lrwxrwxrwx 1 root root 7 Nov 25 19:15 lib -> usr/lib
drwx------ 2 root root 16384 May 15 2024 lost+found
drwxr-xr-x 2 root root 4096 Sep 14 12:01 mnt
drwxr-xr-x 2 root root 4096 Apr 7 2024 opt
dr-xr-xr-x 247 root root 0 Dec 31 1969 proc
drwxr-x--- 6 root root 4096 Dec 2 13:06 root
drwxr-xr-x 22 root root 640 Dec 2 10:38 run
lrwxrwxrwx 1 root root 7 Nov 25 19:15 sbin -> usr/bin
drwxr-xr-x 36 root alarm 4096 Nov 29 12:42 srv
dr-xr-xr-x 12 root root 0 Dec 31 1969 sys
drwxrwxrwt 13 root root 260 Dec 3 00:00 tmp
drwxr-xr-x 8 root root 4096 Dec 2 20:58 usr
drwxr-xr-x 13 root root 4096 Nov 30 17:21 var
Notice sbin is a symlink to /usr/bin
>
> > cat /etc/fstab
> > # Static information about the filesystems.
> > # See fstab(5) for details.
> >
> > # <file system> <dir> <type> <options> <dump> <pass>
> >
> > cat /etc/hosts
> > # Static table lookup for hostnames.
> > # See hosts(5) for details.
> >
> > [alarm@alarm ~]$ blkid
> > /dev/nvme0n1p1: LABEL_FATBOOT="bootfs" LABEL="bootfs" UUID="5A88-04BC"
> > BLOCK_SIZE="512" TYPE="vfat" PARTUUID="b2c58878-01"
> > /dev/nvme0n1p2: LABEL="rootfs" UUID="5170097f-f1f6-42d8-a2ff-8938cbdfa7be"
> > BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="b2c58878-02"
> >
> > >
> > > Hoping to keep partition sizes etc. identical across drives is hard so it
> > > does seem easier to just copy data from one drive to the other.
> >
> > dd is your friend
> >
> > https://www.howtoforge.com/linux-dd-command-clone-disk-practical-example/
> > https://thelinuxcode.com/clone-disk-using-dd-linux/
> >
>
> dd is your friend if you know _exactly_ what you are doing :)
No you just need to pay attention and follow directions, no voodoo required.
>
> >
>
> As ever, the right way is what works for your requirements: sometimes
> people need something straightforward to get them started. Making
> work for yourself at the outset needs to be justified by saving time
> later on, perhaps.
Your standard disclaimer.
A "new" install is a new install. How Linux boots and runs is well known.
DDG is your friend.
>
> All the very best, as ever,
Not really
>
> Andy
> (amaca...@debian.org)
>
--
Hindi madali ang maging ako
