Stuart, would you mind sharing your experience removing snapd from Ubuntu? I'd love to learn how you managed to do it. I'd be happy to get rid of snapd, too. I have started a new thread because it's clearly off-topic to the original thread. On Fri, 29 Apr 2022 at 08:33, Stewart Russell via talk <talk@gtalug.org> wrote:

On Thu, Apr 28, 2022 at 2:15 PM D. Hugh Redelmeier via talk < talk@gtalug.org> wrote:

...

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 manage to have working Ubuntu desktops without snapd, but it's a bit of a fight initially. It may be difficult if you're a Chrome/Chromium user on Ubuntu, as the main distribution channel for those browsers is via snaps. I'll allow a few AppImage packages on my system, but snaps and flatpaks aren't welcome.

Stewart

You can prevent snap from coming back with sudo apt-mark hold snapd Or you can use Linux Mint. It is my choice since Ubuntu 11.04 and Unity. On Sat, Apr 30, 2022, 18:30 Stewart C. Russell via talk <talk@gtalug.org> wrote:

On 2022-04-29 08:50, Val Kulkov wrote:

...

Stewart, would you mind sharing your experience removing snapd from Ubuntu? I'd love to learn how you managed to do it. I'd be happy to get rid of snapd, too.

I followed this guide, which I have to admit I haven't tried on a new 21.10 or 22.04 installation:

Disabling Snaps in Ubuntu 20.10 (and 20.04 LTS) —

https://www.kevin-custer.com/blog/disabling-snaps-in-ubuntu-20-10-and-20-04-...

I'd approach it methodically, making sure you don't wipe out the system accidentally. Once snapd is removed, it stays removed as long as you don't install a package that's a snap in disguise.

Stewart --- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk

| From: Stewart Russell via talk <talk@gtalug.org> | I just did the 22.04 upgrade thing, and it seems that Firefox will be held | at v 99 if you don't have snapd. So beware of old/held packages as you | update. Wow. But it makes some kind of sense. The point of snap is to allow the packager to ignore changes in the environment: the package contains much of its environment. If a distro decides to distribute a snap to reduce the maintenance burden, why would they also distribute a non-snap version. That just increases the burden. Software distributors that don't own a distro have a much more valid reason for using snap: they have no control over changes to the distro. ==> I see no upside in distros distributing things as snaps (unless they are just passing on a snap that someone else created) Another downside of snaps: any bugs, including security bugs, in shared libraries requires the distro to update the library AND the snap publisher to rebuild the snap. What are the chances of that working out well? | Another delightful thing I found is that Ubuntu took its very own special | path in the "Sensible things to do in the Python 2 / Python 3" debacle: | remove Python 2, but don't link python3 to python. Move fast and break | stuff is very tiring when you're constantly getting beaten up like this. Looking on this from afar: is there a right way to do this? Is there a conventional wrong way to do this?

From a purist standpoint, one cannot know what is meant by "python".

If code uses "python", maybe it requires manual intervention to disambiguate what exactly was meant by it. This python2 => python3 transition is a decade-long source of horror and humour to a spectator. It's a common story of bad engineering, writ large. Anecdote: In the FreeS/Wan project, we changed the config file semantics. At the same time, we added a declaration to the config file to specify which version the config file conformed to. Good future-proofing, I thought. A successor project ripped that declaration out. So changes in config file semantics (rare or small) require manual intervention by the user, with no automatic warning.

On Wed, May 11, 2022 at 09:30:41AM -0400, Stewart Russell via talk wrote:

I just did the 22.04 upgrade thing, and it seems that Firefox will be held at v 99 if you don't have snapd. So beware of old/held packages as you update.

Another delightful thing I found is that Ubuntu took its very own special path in the "Sensible things to do in the Python 2 / Python 3" debacle: remove Python 2, but don't link python3 to python. Move fast and break stuff is very tiring when you're constantly getting beaten up like this.

Upstream python says not to call python3 as python. So Unbuntu did it correctly. Python 3 code calls /usr/bin/python3 (or probably better yet /usr/bin/env python3) and legacy python 2 code calls /usr/bin/python. -- Len Sorensen

In a life long ago, we'd have made /usr/bin/python a shell script, containing echo "please run /usr/bin/python3" --dave On 5/11/22 18:04, Giles Orr via talk wrote: On Wed, 11 May 2022 at 14:54, Lennart Sorensen via talk <talk@gtalug.org><mailto:talk@gtalug.org> wrote: On Wed, May 11, 2022 at 09:30:41AM -0400, Stewart Russell via talk wrote: I just did the 22.04 upgrade thing, and it seems that Firefox will be held at v 99 if you don't have snapd. So beware of old/held packages as you update. Another delightful thing I found is that Ubuntu took its very own special path in the "Sensible things to do in the Python 2 / Python 3" debacle: remove Python 2, but don't link python3 to python. Move fast and break stuff is very tiring when you're constantly getting beaten up like this. Upstream python says not to call python3 as python. So Unbuntu did it correctly. Python 3 code calls /usr/bin/python3 (or probably better yet /usr/bin/env python3) and legacy python 2 code calls /usr/bin/python. That actually makes sense. Then the next one can be 'python4' without causing problems. But many distros - and many system administrators will probably just make it 'python'. <sigh> Yup. Here's Fedora 35: $ which python /usr/bin/python $ python --version Python 3.10.4 Debian is guilty of the same thing - which is interesting, because Ubuntu is based on Debian and would have had to take a detour to "do the right thing." Debian and Fedora both also have /usr/bin/python3. -- David Collier-Brown, | Always do right. This will gratify System Programmer and Author | some people and astonish the rest dave.collier-brown@indexexchange.com<mailto:dave.collier-brown@indexexchange.com> | -- Mark Twain CONFIDENTIALITY NOTICE AND DISCLAIMER : This telecommunication, including any and all attachments, contains confidential information intended only for the person(s) to whom it is addressed. Any dissemination, distribution, copying or disclosure is strictly prohibited and is not a waiver of confidentiality. If you have received this telecommunication in error, please notify the sender immediately by return electronic mail and delete the message from your inbox and deleted items folders. This telecommunication does not constitute an express or implied agreement to conduct transactions by electronic means, nor does it constitute a contract offer, a contract amendment or an acceptance of a contract offer. Contract terms contained in this telecommunication are subject to legal review and the completion of formal documentation and are not binding until same is confirmed in writing and has been signed by an authorized signatory.

| From: Dave Collier-Brown via talk <talk@gtalug.org> | In a life long ago, we'd have made /usr/bin/python a shell script, containing | | echo "please run /usr/bin/python3" Bikeshedding for fun: #!/bin/sh echo "$0: please use /usr/bin/python3 (or /usr/bin/python2 if you have to)" >2 exit 42 (Untested, leaving scope for follow-ups.) Didactic explanation of additions: #!/bin/sh make sure that the system runs this with the correct shell. $0 include the name by which the script was invoked in the message (or /usr/bin/python2 if you have to) admit that there are laggards and help them too

2 this should really go to standard error since it is an error message

exit 42 the script should fail: things have gone awry. 42 was chosen to be slightly distinctive. 1 would be more conventional.

On Wed, May 11, 2022 at 06:04:43PM -0400, Giles Orr via talk wrote:

That actually makes sense. Then the next one can be 'python4' without causing problems. But many distros - and many system administrators will probably just make it 'python'. <sigh>

Yup. Here's Fedora 35:

$ which python /usr/bin/python $ python --version Python 3.10.4

Debian is guilty of the same thing - which is interesting, because Ubuntu is based on Debian and would have had to take a detour to "do the right thing."

This is Debian: lsorense@W530:~$ python --version -bash: python: command not found lsorense@W530:~$ python3 --version Python 3.9.2 lsorense@W530:~$

Debian and Fedora both also have /usr/bin/python3.

Debian has that, but not /usr/bin/python unless the user changed it. Both Debian an Ubuntu have a package you can install named: python-is-python3 which installs a symlink. There is also a python-is-python2 package. -- Len Sorensen

| From: Kevin Cozens via talk <talk@gtalug.org> | I have just used dd run under Linux when I have cloned drives in the past. | YMMV. Two problems I can imagine: - the two disks will have partitions with identical UUIDs. This isn't a good idea. The symptoms might be subtle. - if the geometry is different you might get a bad result. I generally find that disk sectors are 4k these days but 512 bytes on a USB disk. I don't know what an NVMe SSD presents as its blocksize. It might well be that Evan's USB thingee preserves the blocksize of the SSD. I don't know.

On 2022-04-28 17:29, D. Hugh Redelmeier via talk wrote:

| From: Kevin Cozens via talk <talk@gtalug.org> | I have just used dd run under Linux when I have cloned drives in the past. | YMMV.

Two problems I can imagine:

- the two disks will have partitions with identical UUIDs.

I was thinking the purpose of the cloning was to replace one drive with another. If you are cloning a drive and keeping them both in the machine it will be a problem if you are referencing drives by UUID. You can always change the drive ID after the cloning process by referencing it by filesystem ID. The fstab file in my machine uses filesystem ID for drive references. The only time I use device UUID is in grub2. Back in the days of grub1 I had it using the filesystem ID.

- if the geometry is different you might get a bad result.

If the size/type of drive is radically different that could be a problem. In that case the new drive can be partitioned as desired (ie. like the old one), then rsync can be to copy the files. -- Cheers! Kevin. http://www.ve3syb.ca/ | "Nerds make the shiny things that https://www.patreon.com/KevinCozens | distract the mouth-breathers, and | that's why we're powerful" Owner of Elecraft K2 #2172 | #include <disclaimer/favourite> | --Chris Hardwick

Many thanks to all, and especially Nigel who has clearly described what is now Plan A. I didn't even know about Clonezilla until Lennart mentioned it yesterday. Then I studied up and it quickly rose to the method of choice, and your detailed instructions have made it dead simple. Up to now I had made a system image and bootable USB recovery USB stick using the MS tools, but a proper clone seems a much cleaner way to do it. (Aside: in preparing for this, in making Kubuntu installation media, Windows recovery and Clonezilla Live, I've discovered that more than three quarters of my collection of USB sticks are useless -- unformattable, unrecognizable by the hardware, or now reporting capacity of 2MB. Miraculously, one of the remaining good ones is decades old with a bootable DR-DOS on it.) Fortunately I am not under pressure to shrink the Windows partition(s); the new drive is large enough that I can leave the existing Windows install as-is and still have plenty of room for the Linux install (as well as a shared-data partition). Evan Leibovitch, Toronto Canada @evanleibovitch / @el56 On Sat, Apr 30, 2022 at 8:54 AM Nigel Auger <subs1@augermax.com> wrote:

I also run multi boot Windows 10 and KUbuntu on my main two systems. Am currently on KUbuntu 20.04 LTS. Here is my way of doing what you want to do.

I have used Clonezilla for years. I boot it from a USB stick. I use it to make regular disk and partition backups as well as migrate and build new systems.

In my experience shrinking Windows system partitions is very problematic due to unmovable files that Windows places high up in the partition. Years ago I found this tool. It was free when I found it. If works (I used it recently on an old Gateway machine with a hard drive) however I am conservative so I take extra steps to ensure success. These extra steps are a lot of work. Many probably wouldn't bother. I describe these steps below.

https://www.diskpart.com/articles/shrink-volume-with-unmovable-files-4348.ht...

NTFS access from linux - I have been accessing NTFS formatted large data drives from Linux for years. NTFS support in Linux seems to be excellent from my perspective. The only caveat is you will probably need to ensure the mount command in the fstab file is configured to give your preferred user full access to that drive. My systems are single user systems so it's easy. For multiuser systems you are probably better to seek the advice of others on this forum who are far more knowledgeable than I am. Here is an example fstab entry I use:

#UUID=F474B7AA74B76DCC /home/augern/WDp2 ntfs-3g defaults,nofail,uid=1003,gid=1003,umask=000,dmask=027,fmask=137 0 0

MY STEPS to ACCOMPLISH WHAT YOU WANT TO DO

1) Use Clonezilla to clone your original M.2 SSD onto the new M.2 SSD. Just use straight full disk image, NOT individual partitions because you want to ensure all of the boot sector info is cloned. Since you are cloning onto a larger disk this should just work. There will be empty space at the end of the new drive. Use the beginner mode in Clonezilla.

2) Swap out the old smaller SSD and swap in the new larger SSD into your target system.

3) Boot the system into Windows. You might have to reboot once or twice to allow Windows to do whatever it does when the environment changes.

Preparing and shrinking Windows.

4) Install AOMEI Partition Assistant.

5) If you have the patience, stamina, copy all user data such as documents, photos, videos, etc. to a backup drive and consider temporarily deleting them from the Windows system partition. As I wrote above I am conservative so this is an optional step, probably not necessary but it will reduce the burden on the partition shrinking tool.

6) Run Windows Disk Clean as administrator. You want to ensure all the crap from Windows updates and upgrades is deleted. These files can run into many gigabytes of data. Also ensure you click on the tab in Disk Clean and select delete all old restore points as these files also can be quite large and are unnecessary since you have a cloned copy of your system should something go wrong and you need to start over.

7) From your administrator account in Windows disable hibernate and disable the page file (virtual memory). Check to make sure the files have been deleted. They are hidden system files. If they are still there delete them.

8) Use AOMEI Partition Assistant to shrink your Windows system partition.

9) When finished shrinking the Windows partition, re-enable hibernate and the page file and copy back over any user data files you deleted to speed the process up.

10) Once you are happy Windows is stable and working, make a Clonezilla backup image of the entire disk so that when something goes wrong during Linux installation or some unplanned Windows Update and your system gets wrecked, you can recover it in 30 odd minutes rather than having to start over from scratch.

11) You are now ready to install your Linux system(s). Use the normal partition tools to set up your disk the way you want it.

On Fri, Apr 29, 2022 at 9:22 PM Lennart Sorensen via talk <talk@gtalug.org> wrote:

...

...

Hi all.

This topic is one I hope will be on many peoples' minds as they encounter frustration (and in some cases a dead end) moving their Windows 10 systems to Windows 11. This may soon become the source of a multi-stakeholder public campaign, but that's just in the planning stages.

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, especially since there's a recent LTS release of Kubuntu, my traditional distro of choice. Plus, according to ProtonDB, my game might just run well natively on Linux <https://www.protondb.com/app/255710>!

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

On Thu, Apr 28, 2022 at 01:35:38AM -0400, Evan Leibovitch via talk wrote: 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?

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?

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?

I have avoided them so far by not using a distribution with such silly additions. :)

I think even Mint Linux based on Ubuntu has removed it.

As for cloning and resizing, clonezilla should do the job well.

-- Len Sorensen --- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk