mersenneforum.org > EdH Tribulations of Upgrading Ubuntu from 16.04 LTS to 20.04 LTS
 Register FAQ Search Today's Posts Mark Forums Read

 2020-10-21, 22:33 #2 paulunderwood     Sep 2002 Database er0rr 349610 Posts 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 apt-get update and then apt-get dist-upgrade. I'll let you know if there are any hitches.
 2020-10-21, 22:55 #3 retina Undefined     "The unspeakable one" Jun 2006 My evil lair 5,879 Posts Why do you need to upgrade? If it was working why try to fix it?
2020-10-21, 22:57   #4
VBCurtis

"Curtis"
Feb 2005
Riverside, CA

32×7×71 Posts

Quote:
 Originally Posted by retina Why do you need to upgrade? If it was working why try to fix it?
20.04 has a working (or possible-to-make-work) open-mpi. 16.04 and 18.04 do not.

 2020-10-21, 22:57 #5 EdH     "Ed Hall" Dec 2009 Adirondack Mtns 65658 Posts 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.
2020-10-22, 02:13   #6
paulunderwood

Sep 2002
Database er0rr

23·19·23 Posts

Quote:
 Originally Posted by retina Why do you need to upgrade? If it was working why try to fix it?
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
Building dependency tree
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:
apt-get upgrade
Building dependency tree
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
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
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
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
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:
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-image-4.19.0-12-amd64
linux-image-amd64
E: Sub-process /usr/bin/dpkg returned an error code (1)

Last fiddled with by paulunderwood on 2020-10-22 at 02:34

2020-10-22, 02:41   #7
paulunderwood

Sep 2002
Database er0rr

23×19×23 Posts

Quote:
 Originally Posted by EdH 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.
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.

Last fiddled with by paulunderwood on 2020-10-22 at 02:49

2020-10-22, 02:44   #8
EdH

"Ed Hall"
Dec 2009

5×13×53 Posts

Quote:
 Originally Posted by retina Why do you need to upgrade? If it was working why try to fix it?
Quote:
 Originally Posted by VBCurtis 20.04 has a working (or possible-to-make-work) open-mpi. 16.04 and 18.04 do not.
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.

2020-10-22, 02:49   #9
EdH

"Ed Hall"
Dec 2009

5×13×53 Posts

Quote:
 Originally Posted by paulunderwood 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.
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.

2020-10-22, 04:12   #10
phillipsjk

Nov 2019

6510 Posts

Quote:
 Originally Posted by EdH 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.

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

https://www.debian.org/releases/jess...n.html#systemd

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).

Last fiddled with by phillipsjk on 2020-10-22 at 04:14 Reason: unclean "mount" -> "shutdown"

 2020-10-22, 11:26 #11 Xyzzy     "Mike" Aug 2002 27×61 Posts 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.

 Similar Threads Thread Thread Starter Forum Replies Last Post ckdo PrimeNet 3 2018-03-12 15:24 foxmccloud123 Hardware 14 2013-05-19 06:09 ET_ Linux 9 2012-03-05 20:04 fivemack Linux 6 2008-05-24 12:51 apocalypse Linux 3 2007-12-22 23:24

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

Wed Nov 25 23:28:18 UTC 2020 up 76 days, 20:39, 3 users, load averages: 1.63, 1.40, 1.34