[GTALUG] Back to basics: upgrading from Windows to Linux

[D. Hugh Redelmeier]

| From: Evan Leibovitch via talk <talk at gtalug.org>

| Now for the personal angle.

| Some ago I installed Windows on a desktop I use a lot. It replaced Linux
| because that was incapable of running the one game I like playing. I even
| gave a talk to GTALUG about that move, about Windows Subsystem for Linux
| and the things I thought were better about the Windows desktop.
| 
| Turns out I was wrong. So very, very wrong. And now I can't wait to go back
| to my Linux desktop,

Why do you now feel you were wrong?  Or is that a subject for your next 
talk?

| But it's been a long time since I've done this so I have some remedial
| questions to ask from this group's wisdom ... to help me change from a
| Windows install to a dual boot, priority Kubuntu:
| 
|    1. My motherboard takes a single M.2 SSD for my one and only drive. I
|    have a larger M.2 card that I'd like to replace it with, cloning my
|    existing setup to the new drive (in a temporary USB enclosure) then
|    installing and shrinking the Windows partition in anticipation of the Linux
|    dual-boot install. Can anyone recommend a good tool for doing the disk
|    clone? Or am I better off to just fresh-install Windows on the new drive,
|    and restore my data from the old one?

You've really got three independent steps: Windows partition shrink,
disk upgrade, and system upgrade.  You can probably do them in any
order but the order I listed them in has advantages.

- less data to copy
- fewer partitions to copy
- fewer systems to break.

A lot of after-market drives come with software to migrate Windows.
I've never used them, but I suspect that they work and are easy.

There are free (as in beer) programs to do that job too.  I've never
used them.

When I've done this, I've done it the brute-force way.  I don't want
to describe the tricky bits:, mostly involving UUIDs.

Here are steps that avoid brute force:

a) do a backup of what you care about.  Really.

b) shrink the Windows partition.  This results in less to copy.  So
   you might as well do it at the start.

b1) If you want to shrink it only modestly, leaving 50% or more of the
    allocation, Windows has built-in tools to do that.

b2) If you wish to shrink more, you can boot a live Linux from a USB
    stick and use gparted to adjust the partition sizes.
    Be sure to reboot Windows after this step because Windows might
    find and fix some loose ends left by gparted (this may no longer
    be needed but better safe than sorry).

c) use the Windows cloning program to copy Windows to the new drive.

d) swap the drives (physically).  I expect that the new one can be
   booted from.

d) install the Linux of your choice.

|    2. I want to have one partition for data that is visible regardless if I
|    boot Linux or Windows. Previously the most reliable filesystem readable by
|    bothwas FAT32. Should I still do that? Is Linux support for NTFS good
|    enough now? Even better, can Windows be taught to read ext4?

VFAT is the most likely to work.  Some attributes get lost.

Linux NTFS probably works but I don't know that with certainty.

extX on Windows is probably more of a pain (not based on actual
experience).  It isn't mainstream so it probably has bugs.

|    3. I've never used snap or flatpack before. Others have told me to
|    install as much native (ie, .deb packages) as possible, use flatpack when
|    it's the only option and uninstall snap. Any comments or caveats here? And
|    why did app installation sources become needlessly complex?

That's partly based on religion.  I share that religion.

On the other hand, Canonical is the owner of Snap and pushes it hard.
So on a Ubuntu system you may end up needing to use Snap.  I think
that Ubuntu developers are moving core functions to Snap.

I've read in LWN that Chrome and Chromium are difficult and
unrewarding for distros to build and that Snap or Flatpak would be a
partial solution to this.

Generally Snap and Flatpak are supposed to be mostly invisible machinery.