Getting new hardware - can I just move the disk?

[Liam Proven]

On Sun, 10 Oct 2021 at 11:49, Bo Berglund <bo.berglund at gmail.com> wrote:
>
> Good to hear,
> I had in mind to image the whole existing drive over to the new machine's SSD
> drive since they are of equal size and it is less than 50% full (mostly videos).

Should be fine.

> Of course if that works then I will have to do the 'do-release-upgrade' to get
> to 20.04 LTS afterwards.
>
> >BIOS vs UEFI
>
> This might be a problem, the current machine was most likely built before UEFI
> was invented so baybe Ubuntu cannot boot from this disk if the new Lenovo only
> uses UEFI?

So test it!
Boot the new PC from (say) FreeDOS on a USB key. Install it to a small
primary FAT16 partition, using MBR partitioning. See if it boots. If
it does, Ubuntu will be fine.

> This is a machine that was originally installed with Ubuntu 16.04 and
> release-upgraded to 18.04 some years back, it still uses the traditional names
> eth0, lo, tun0, tun1 if viewed with ifconfig, which is also available...

Shouldn't matter. My main laptop started out on 13.10 and is on its
3rd generation of replacement hardware now.

> I guess you mean hardware drivers? If that is the case will the system just hang
> on boot? Or will it come up so it can then check for drivers on-line?
> My 18.04 installation is fully up-to-date at least.

It should just work.

> xorg.conf suggests that you are using a system with a desktop, mine is a
> *server* with only command line access, no desktop available. So I guess this
> does not affect me? Possibly making things simpler?

It should do, yes.

> Well, I have this in /etc/fstab so I guess it is moved to use UID-strings
> instead of drive names:
>
> # <file system> <mount point>   <type>  <options>       <dump>  <pass>
> # / was on /dev/sda1 during installation
> UUID=ec0e8708-8a6a-4bbf-93ba-0a09b1e2ddc1 /               ext4
> errors=remount-ro 0       1
> # swap was on /dev/sda5 during installation
> UUID=a77b40db-2377-4d25-b304-8d233664d1ca none            swap    sw
> 0       0
>
> And checking with df shows sda in use
> (I have removed lines showing external mounts):

If it were me, I'd change to /dev/sdX notation, copy it, then once
working, change it back. Depending on how you copy the disks, GUIDs
might not be copied.


> If I mirror the existing drive onto the new machine's SSD, then the original
> will stay where it is. But then the UUID labels in FSTAB probably need to be
> changed before I can boot on the new system, right?

This is why my suggestion above.

> BTW:
> What is the "best/easiest" way to make a clone of the existing drive onto the
> new SSD drive? I would not necessarily need to transfer all of the video files
> at this stage. They make up the bulk of used space (like 150G or so).

* make and test a bootable USB key with 20.04
• boot from USB, run Gparted
• partition the new machine's drive with MBR. No partitions; just an
empty partition table
• get an external SATA to USB cable -- they cost like €5 or something
• remove the old server's drive; attach it to the new one by USB
• boot from USB again
• copy the root partition from the old disk the SSD

I suggest this order so there is no way to accidentally partition the
wrong drive.

> And my spare seldom used monitor has VGA and DVI only...

You can get cables to connect VGA to DVI and DVI to HDMI. They're
quite cheap and worth having in the spares box.

It is worth knowing that DVI-HDMI cables work both ways: you can
connect an old DVI monitor to an HDMI port. I bought mine to use a new
HDMI monitor on an old PC with the old DVI port, but it also works to
connect my HDMI-only Raspberry Pi to an old DVI-only monitor.


-- 
Liam Proven ~ Profile: https://about.me/liamproven
Email: lproven at cix.co.uk ~ gMail/gTalk/FB: lproven at gmail.com
Twitter/LinkedIn: lproven ~ Skype: liamproven
UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053