[mythtv-users] ubuntu upgrade - hazy recollections

John Pilkington johnpilk222 at gmail.com
Thu Dec 20 10:53:47 UTC 2018

On 20/12/2018 00:45, Stephen Worthington wrote:
> 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/

Stephen:  Many thanks for all that.  It's well worth having it 
bookmarked *on another machine*

I think my point about the 'cleanup' is that until a general user has 
access to a system that behaves mostly like the old one 'they' will be 
in unfamiliar ground.  Don't try to do anything that isn't essential 
until you've landed.


More information about the mythtv-users mailing list