mersenneforum.org

mersenneforum.org (https://www.mersenneforum.org/index.php)
-   EdH (https://www.mersenneforum.org/forumdisplay.php?f=152)
-   -   Tribulations of Upgrading Ubuntu from 16.04 LTS to 20.04 LTS (https://www.mersenneforum.org/showthread.php?t=26113)

EdH 2020-10-21 22:16

Tribulations of Upgrading Ubuntu from 16.04 LTS to 20.04 LTS
 
This will probably seem like a rant. Maybe it is! Maybe this will just be a funny story some day. . .

I have many machines that I decided to upgrade to 20.04 LTS (via 18.04 LTS) now that I can make openmpi and ecmpi run on Ubuntu 20.04

All my machines are run remotely. Except for some laptops and all-in-ones, they're headless and many are not in a real easy to reach location.

Of course, I did a few that are closer at hand before trying to upgrade the bulk, but that didn't save me. Here's a list of trouble spots:

NONE (well, mostly none) of my factoring programs work any more. I have to recompile and reinstall GMP, GMP-ECM, Msieve, YAFU, CADO-NFS, ecmpi and, of course, many of these have to be done in a particular order. But, worse yet, several wouldn't work with their original folders using make clean, etc. Nooo. . . I have to start fresh with a new folder with programs like YAFU and CADO-NFS. And, it's not because they're in UPPER case - ecmpi behaved that way, too.

Ah, but let's add in that after several successes, I found that the auto login for my headless remote machines was turned off, so my VNC connections no longer worked. At least my SSH sessions allowed me to remotely repair that BS.

But, wait! There's more! Some machines didn't make it past 18.04 because when they reset to complete the upgrade they decided they could no longer reach out to the Internet! I can reach them over the LAN, but that's where they stop. If I can't get them to upgrade to 20.04, they are going to be useless and I'll probably have to wipe them and put a new 20.04 install on them.

But, wait! Also, the 20.04 upgrade changes the "Don't Suspend" to "Suspend in 20 minutes!" Guess how I found that out! Did I mention my machines are uncomfortable to physically access?

Back to the LAN-Locked 18.04 machines: If anyone is still reading, if they actually looked at this tread in the first place, any ideas? All my machines are set up with static IPs, but for these I went back and forth with DHCP and Static just to see if they might iron themselves out, but no joy. I also tried different DNS addresses between the router base and Google's 8.8.8.8 and 1.1.1.1 that I heard of somewhere. In case it matters, the title bar icon shows it is not working correctly by placing a question mark version where the dual arrows used to appear. I can ping the router and 8.8.8.8 or 1.1.1.1, but not other IPs or DNS entries.

If anyone has any thoughts about the Internet issue, I wouldn't mind reading them. I "think" I have all the rest under control, even if it is going to take a long time to get these machines factoring again.

paulunderwood 2020-10-21 22:33

I have never had any such problems with Debian. In fact I will be upgrading from Buster to Bullseye any day soon. Some parts of ROCm require later versions of Python. I simply change the sources list, run [C]apt-get update[/C] and then [C]apt-get dist-upgrade[/C]. I'll let you know if there are any hitches.

retina 2020-10-21 22:55

Why do you need to upgrade?

If it was working why try to fix it?

VBCurtis 2020-10-21 22:57

[QUOTE=retina;560623]Why do you need to upgrade?

If it was working why try to fix it?[/QUOTE]

20.04 has a working (or possible-to-make-work) open-mpi. 16.04 and 18.04 do not.

EdH 2020-10-21 22:57

Oddly, all my Debian installs broke when I upgraded either to or from Jessie. I don't remember which now. I do use a couple SSH only, but I can't login to a GUI session at all anymore, locally or remote. I've posted about it somewhere on the forum in the distant past. Basically, the login screen will not let me enter the password. It just erases it as I type saying that it was incorrect. I finally gave up and went to Ubuntu almost exclusively, trying to simplify.

paulunderwood 2020-10-22 02:13

[QUOTE=retina;560623]Why do you need to upgrade?

If it was working why try to fix it?[/QUOTE]

If this question was aimed at me...

My apt package manager is also broken with unmet dependencies, something to do with dkms and a kernel. I have spent many hours trying to fix apt in the past and thought an upgrade to Bullseye would fix a lot.

[code]
apt-get install rocm-gdb
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
rocm-gdb : Depends: libpython3.8 but it is not installable
[/code]

[code]
apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages have been kept back:
rocm-gdb
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
6 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n]
Setting up linux-image-4.19.0-11-amd64 (4.19.146-1) ...
I: /initrd.img.old is now a symlink to boot/initrd.img-4.19.0-11-amd64
/etc/kernel/postinst.d/dkms:
Error! Could not locate dkms.conf file.
File: /var/lib/dkms/amdgpu/3.5-32/source/dkms.conf does not exist.
run-parts: /etc/kernel/postinst.d/dkms exited with return code 4
dpkg: error processing package linux-image-4.19.0-11-amd64 (--configure):
installed linux-image-4.19.0-11-amd64 package post-installation script subprocess returned error exit status 1
Setting up linux-headers-4.19.0-11-amd64 (4.19.146-1) ...
/etc/kernel/header_postinst.d/dkms:
Error! Could not locate dkms.conf file.
File: /var/lib/dkms/amdgpu/3.5-32/source/dkms.conf does not exist.
run-parts: /etc/kernel/header_postinst.d/dkms exited with return code 4
Failed to process /etc/kernel/header_postinst.d at /var/lib/dpkg/info/linux-headers-4.19.0-11-amd64.postinst line 11.
dpkg: error processing package linux-headers-4.19.0-11-amd64 (--configure):
installed linux-headers-4.19.0-11-amd64 package post-installation script subprocess returned error exit status 1
Setting up linux-headers-4.19.0-12-amd64 (4.19.152-1) ...
/etc/kernel/header_postinst.d/dkms:
Error! Could not locate dkms.conf file.
File: /var/lib/dkms/amdgpu/3.5-32/source/dkms.conf does not exist.
run-parts: /etc/kernel/header_postinst.d/dkms exited with return code 4
Failed to process /etc/kernel/header_postinst.d at /var/lib/dpkg/info/linux-headers-4.19.0-12-amd64.postinst line 11.
dpkg: error processing package linux-headers-4.19.0-12-amd64 (--configure):
installed linux-headers-4.19.0-12-amd64 package post-installation script subprocess returned error exit status 1
Setting up linux-image-4.19.0-12-amd64 (4.19.152-1) ...
I: /initrd.img is now a symlink to boot/initrd.img-4.19.0-12-amd64
/etc/kernel/postinst.d/dkms:
Error! Could not locate dkms.conf file.
File: /var/lib/dkms/amdgpu/3.5-32/source/dkms.conf does not exist.
run-parts: /etc/kernel/postinst.d/dkms exited with return code 4
dpkg: error processing package linux-image-4.19.0-12-amd64 (--configure):
installed linux-image-4.19.0-12-amd64 package post-installation script subprocess returned error exit status 1
dpkg: dependency problems prevent configuration of linux-headers-amd64:
linux-headers-amd64 depends on linux-headers-4.19.0-12-amd64; however:
Package linux-headers-4.19.0-12-amd64 is not configured yet.

dpkg: error processing package linux-headers-amd64 (--configure):
dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of linux-image-amd64:
linux-image-amd64 depends on linux-image-4.19.0-12-amd64; however:
Package linux-image-4.19.0-12-amd64 is not configured yet.

dpkg: error processing package linux-image-amd64 (--configure):
dependency problems - leaving unconfigured
Errors were encountered while processing:
linux-image-4.19.0-11-amd64
linux-headers-4.19.0-11-amd64
linux-headers-4.19.0-12-amd64
linux-image-4.19.0-12-amd64
linux-headers-amd64
linux-image-amd64
E: Sub-process /usr/bin/dpkg returned an error code (1)
[/code]

paulunderwood 2020-10-22 02:41

[QUOTE=EdH;560625]Oddly, all my Debian installs broke when I upgraded either to or from Jessie. I don't remember which now. I do use a couple SSH only, but I can't login to a GUI session at all anymore, locally or remote. I've posted about it somewhere on the forum in the distant past. Basically, the login screen will not let me enter the password. It just erases it as I type saying that it was incorrect. I finally gave up and went to Ubuntu almost exclusively, trying to simplify.[/QUOTE]

That most likely a legacy dot file -- beginning with "." -- in your home directory. I think is a security one. ls -a with show it. I am pretty sure if you created a new user with adduser then that user would be able to log in with the GUI.

EdH 2020-10-22 02:44

[QUOTE=retina;560623]Why do you need to upgrade?

If it was working why try to fix it?[/QUOTE]

[QUOTE=VBCurtis;560624]20.04 has a working (or possible-to-make-work) open-mpi. 16.04 and 18.04 do not.[/QUOTE]
Not sure how I missed these. . .

Actually, openmpi was working quite well with 16.04, but before I knew that 18.04 wasn't going to, I set up some new (to me) systems with 18.04. When I couldn't get them to work, I patiently waited for 20.04 to come out to see if openmpi would work again. I upgraded some of the 18.04 systems and was able to "enjoy" openmpi again. But, I also discovered that openmpi, although working, wouldn't work between 16.04 and 18.04 systems. So, I started upgrading everything to 20.04, looking toward the EOL for 16.04 in a few months.

EdH 2020-10-22 02:49

[QUOTE=paulunderwood;560640]That most likely a dot file -- beginning with "." -- in your home directory. I think is a security one. ls -a with show it. I am pretty sure if you created a new user with adduser then that user would be able to log in with the GUI.[/QUOTE]
I remember trying to chase it down for quite some time before giving up. I do have a couple still running. Maybe after I get the farm back up to at least near where it was before, I may revisit the Debian issue.

phillipsjk 2020-10-22 04:12

[QUOTE=EdH;560642]I remember trying to chase it down for quite some time before giving up. I do have a couple still running. Maybe after I get the farm back up to at least near where it was before, I may revisit the Debian issue.[/QUOTE]


That is the release they moved over to Systemd. (Ubuntu did as well, since they are based on Debian).


[URL]https://www.debian.org/releases/jessie/i386/release-notes/ch-whats-new.en.html#systemd[/URL]


The problem with systemd is that it tries to do too much. It also tries to automagically configure everything, Windows style. Also to get the touted fast boot times, aggressive time-outs are used. This essentially makes the exclusive use of journaling filesystems a requirement: since filesystem checks are never given time to complete after an unclean [shutdown]. It also prevents the Ubuntu Live DVD from reliably booting on at least one system. (Sequential loading is actually faster for optical media with horrible (1/3 second) seek times)


The systemd-free fork of Debian is called Devuan. However, it inherited the aggressive time-outs on boot and shut-down. This required me to write a shut-down wrapper script on my "white elephant" machine: since saving mprime state to a USB stick (with BTRFS) was taking over 30 seconds (would lose half an hour of work otherwise).

Xyzzy 2020-10-22 11:26

The not-so-simple solution is to have all of these programs turned into packages that can be installed with the distribution's package manager.


All times are UTC. The time now is 15:23.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.