[mythtvnz] Mythbuntu fails to start

Stephen Worthington stephen_agent at jsw.gen.nz
Thu Jan 11 01:22:13 GMT 2018


On Wed, 10 Jan 2018 19:53:45 +1300, you wrote:

>My Mythtv box has developed a problem.
>
>There is no display and it appears that the desktop has not started.
>
>I can boot a live USB (Boot Repair disk) and it runs fine.The hard 
>drives show no problems.
>
>I've tried a monitor off another computer - same results.
>
>The weird thing is that I have another cloned drive and it behaves the 
>same it sounds normal during boot up - like it is loading stuff into 
>memory etc.
>
>I've tried to boot into recovery mode and to  boot earlier kernels.
>
>I can use R-E-I-S-U-B command to reboot which indicates some parts of 
>the system is operational but perhaps XFCE isn't starting.
>
>I'm resigned to retrieving the database backup and various modified 
>system files and  doing a re-install tomorrow - unless anyone has any 
>suggestions that might correct the situation.
>
>I'll check form any replies tomorrow morning
>
>Cheers
>
>Paul

If this is a modern systemd based Ubuntu, then failing to boot up
properly can be due to systemd doing extra things during the boot,
causing timeouts on later parts of the boot process.  It happens to me
when systemd runs fsck automatically at boot time.  Another cause can
be a bad network mount, or a required drive failing to mount (eg due
to corruption in the filesystem or a bad cable).  I have never
bothered to track down why systemd fails to complete the rest of the
boot correctly - what I do is figure out what the trigger was (eg
fsck) and fix that.

You can do a repair boot by selecting that option in the grub menu.
That will give you command prompt where you can look at the logs,
figure out the trigger, and fix that, then reboot to normal multi-user
mode.

The other way to figure out what is going on is to enable the systemd
early debug shell:

systemctl enable debug-shell.service

In your case, you should be able to do a repair boot and execute that
command from there.  Then when you boot up, as soon as enough things
are working that a shell will run, systemd will start a root shell
available on Ctrl-Alt-F9.  This is a big security hole when it is
enabled as the early debug shell does not require a login (it runs
before login is available) and it runs as root.  But it allows you
full access to all the command line tools needed to work out what
systemd is doing during bootup.  I would start with:

systemctl list-jobs

to see what jobs systemd is running and what ones are currently
waiting to start.  You may find several fsck jobs listed.  Another
useful command is:

ps -e | grep -i fsck

And you can access the log files, or run journalctl to read the
journal files.

BTW If, like me, you hate having to type "systemctl" and "journalctl"
all the time, then I would recommend having some aliases like these in
your /root/.bash_aliases file:

root at mypvr:~# cat .bash_aliases
alias sc='systemctl'
alias jc='journalctl'
alias sco='systemctl stop'
alias scs='systemctl start'
alias scr='systemctl restart'
alias scst='systemctl status'



More information about the mythtvnz mailing list