All I can think of is looking in /etc/rc.local (that gets called at the end of each runlevel, but normally does nothing).

Apart from that I've run out of ideas for what could be calling kmod. So I'd suggest ignoring the message, the script doesn't do anything when called with the stop parameter.

Exactly when does that message come out? Is it when you boot the system, log on, log off or shut it down?

less /etc/init.d/kmod should tell you what kmod is (unless all the comments are missing).

Try this:

ls -l /etc/rc?.d/*kmod*
lrwxrwxrwx 1 root root 14 May  9  2018 /etc/rcS.d/S09kmod -> ../init.d/kmod

You should get only 1 line, a symlink that tells the OS to run kmod start when bringing the system up. I suspect you have a stop link somewhere (it will be probably named something like K09kmod).

For belt and braces try ls -l /etc/rc?.d/ | grep kmod which searches the destination of the symlink. If still stuck grep meaningless /etc/rc?.d/* in case there is a stray copy of kmod somewhere.

cat /proc/cmdline should also show the boot command line. On my system it matches the entry for the last boot in /var/log/syslog

I would *assume* that a merged /usr would have moved everything in /sbin to /usr/sbin and replaced /sbin with a symlink to /usr/sbin (and similar for /bin, /lib, etc). But that's probably too simple for the designers to think of.

Is there a /install/gtk/initrd.gz in your / or /boot ? If there's a /initrd.img on your system is it a symlink to somewhere?

I'm not an expert, but I know that the system loads an initrd.img early in boot processing (possibly compressed). So I'd expect that entry to point to the one the system should use. So removing that entry might stop your system booting.

Does your /etc/default/grub say anything like:

# For full documentation of the options in this file, see:
#   info -f grub -n 'Simple configuration'

If so try that.

Post that to the github discussion. It might point then towards the bug. (Sorry if you'e already done that).

Is there a /boot directory? I assume you are running as root so will be able to write to /boot

That's all I can think of, but sometimes checking silly things can find silly problems.

What happens if you tell it to use googlemail.com instead of gmail.com ? I have one system using kmail where it insists on using the wrong type of auth for gmail.com but I can get it to work with googlemail.com (it's kmail being "clever" that causes the problem). I can't check details on that system just now though, sorry.

That took quite a lot of puzzling to work out.

From man locate
locate reads one or more databases prepared by updatedb(8) and writes file names matching at least one of the PATTERNs to standard output, one per line.

So if updatedb ran when the filesystem was not mounted it would find the "hidden" files and put them into the database. So running locate repeatedly would always show them, until the next updatedb run.

Read the man page for env.

#!/usr/bin/env python3

Will only work if python3 is in it's $PATH. Try which python3 to make sure it's installed on your system.

First try running memtest86 for a few hours. Run it single threaded first. If it doesn't hang or report any faults try it again multi threaded. If memtest86 crashes as well then the OS must be innocent.

Next boot Linux and run watch sensors in a terminal window. That will show how hot the CPU etc are. If it gets over 100C then check all fans are OK, there's no fluff on the CPU, etc.

I've just found (from an article in Linux Magazine) that there's a program called adequate which sanity checks packages for violations of Debian package guidelines.

Install with apt-get install adequate and read it's man page for details (it won't usually need to be run as root). From a quick check it should find various packaging errors, although there can be false positives. And it only checks if a package is correctly packaged, not if it actually does what it is supposed to. But it looks worth adding to recommended workflow.