[mythtv-users] ubuntu upgrade - hazy recollections

Stephen Worthington stephen_agent at jsw.gen.nz
Thu Dec 20 00:45:23 UTC 2018


On Wed, 19 Dec 2018 16:12:36 +0000, you wrote:

>I started off adding this to the 'new drive won't boot' thread, but 
>perhaps it's better stand-alone.
>
>I had boot problems a couple of weeks ago in updating my old laptop from 
>kubuntu 16.04 to 18.04   I have the impression that they arose mainly 
>from electing to clean up unwanted files _during_ the upgrade process, 
>and maybe from having several ppas enabled.  Only the original 'small' 
>80 GB disk involved. (My first disk drive was a DEC RK05, cartridge 
>capacity 5 MB, in a 21 inch rack.)
>
>IIRC the upgrade seemed to stagnate and I tried to reboot, but 'A stop 
>job is running' and the network wasn't found: 'Check your network 
>settings...'  Grrr.
>
>Eventually I resorted to a boot-repair disk, added a boot parameter 
>apparently required for the intel GM965 video chip, and 'reconfigured' 
>lightdm.  I think it's using sddm now.  All completely dependent on 
>having google etc on another machine.  As always, I run myth in konsole 
>tabs, so at least I can usually tell that the network is down...
>
>John P

When you do a version upgrade, all PPAs are disabled before the
upgrade is done.  The automatic cleanup of unwanted files is normally
harmless - I believe it just does the same as "apt autoremove".  So it
will remove all installed packages that are not set as manually
installed and are not requested by other packages.  The removal
process is not a purge - all the config files remain.  So if a package
you need does get autoremoved, then you can just manually reinstall it
and it will still have the correct config.

If you were previously relying on something from a PPA, you need to go
to /etc/apt/sources.list.d and /etc/apt/sources.list and check for all
the PPAs that may have been disabled.  Uncomment them, update them to
the new version of the PPA (and hope that there *is* a version of the
PPA that matches your new system version).  Then run:

apt update
apt dist-upgrade
apt autoremove

If you are having boot problems with systemd not bringing up
everything so you can not get proper access to your system, there are
a couple of options.  First, you can do a repair boot by selecting
"Recovery mode" from the grub menu.  That brings up a list of various
options including one for booting to a root console (I forget the name
but it is fairly obvious).  If you select that, you will get a boot to
a root console where you can edit things, look at log files and run
journalctl and systemctl.  The problem with fixing things that way is
that you can not get live information about how the boot is working -
all you can see is logged information from the failed boot.

To see live what systemd is waiting on, you can enable an early root
console.  You do that by editing the kernel command line from the grub
menu, before the kernel is booted.  I think it is the 'e' key that you
use to edit the kernel command line, but it is a long time since I
last did it, so check the documentation.  Add this at the end of the
kernel command line:

systemd.debug-shell=1

Then very early in the boot process, systemd will start a root console
available on Ctrl-Alt-F9.  No login is needed (as the login capability
is not present at the time it is started).  From that console, you can
do journalctl and systemctl commands to see what systemd is doing. Try
"systemctl list-jobs" to start with, and look for what jobs are listed
as "Waiting".  When I was having booting problems with 16.04 after a
kernel update, I found that the network was waiting to come up - I
could see that the job for the network was always "Waiting".
Eventually, I traced this down to a "udevadm settle" command being
used in the network scripts to wait for the hardware to be stable
before it started the network.  But the new kernel had a bad driver
for my old PVR-500 card, which was causing udev messages all the time
and preventing "udevadm settle" from exiting.  So from the Ctrl-Alt-F9
console, I was able to use the ps command to find the PID for the
"udevadm settle" command and kill it, and then the boot completed
normally.

See here for systemd debugging:

https://freedesktop.org/wiki/Software/systemd/Debugging/


More information about the mythtv-users mailing list