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

John



More information about the mythtv-users mailing list