Fair point but as Sam said earlier we are very busy working on actually developing OSMC and with real life limiting the amount of time that we can spend on OSMC (I’m renovating a house for example, and Sam is finishing a degree, and I know the other devs are quite busy too) that often doesn’t leave much time for the forum, so we do rely to a degree on users supporting other users, which is the way things work in most good forums.
It also depends on the nature of the problem - for example if its something I know the answer to off hand I will generally find time to reply, but some problems can’t be investigated or solved without trying to duplicate the issue first hand - and if that means installing some random 3rd party software that is causing the issue (which I have never heard of before, don’t know how to use or don’t have the hardware to use) then more often than not there just isn’t the time to do that. (This time would take away from actually developing OSMC)
Although OSMC is effectively an open source Debian derivative which allows you to install pretty much whatever you want to on it, that doesn’t mean that we are able to provide what amounts to Linux consulting services for any and all random 3rd party applications to make sure they are working - we just can’t physically do that.
Obviously there are some programs that are frequently used in conjunction with Kodi such as tvheadend that we will try our best to get working, or if the issue seems to be a significant underlying issue in the way the OS is configured we will investigate. But random program x not working we often just can’t do anything about.
Of course other users who solve the problem with program x are welcome to share the solution with us and other users, and if it makes sense to tweak OSMC in a way that makes it more compatible with said program we will certainly consider doing this.
As a matter of fact you can’t leave init=/bin/bash in your cmdline.txt - this will boot directly to a shell prompt and prevent normal system startup, so I’m not sure why it didn’t seem to be working for you…(also adding this is nothing to do with ssh access - ssh is provided by a service that runs much later - in fact init=/bin/bash will disable ssh since it will disable all service startup)
You’ll be pleased to know I have added a feature to hold down shift at the beginning of boot to go directly to a recovery console:
This will run an fsck, then give you a root bash prompt with normal startup (including systemd) disabled, so this is 99% guaranteed to be accessible even if your startup sequence is badly messed up. This is fairly similar to init=/bin/bash but with a few frills like mounting /proc, /sys, remounting root rw and mounting /boot automatically for you, making it a lot more convenient to use.
A second recovery option that will be added is the option to boot to a normal getty tty login instead of Kodi by holding down Ctrl during boot:
The advantage of this method over the first is that it is a full normal boot with all services running, network started and so on, but minus Kodi - ideal for fixing problems with Kodi or just if you want to log in to a console without loading Kodi first then quitting it.
In the case that the normal boot process can’t get this far you can still use shift for the recovery console.
Finally Ctrl+Shift held down during boot will run a full apt-get update && apt-get dist-upgrade using the familiar blue progress screens to help get out a of a situation where an update can’t be done via the OSMC settings addon for some reason.
I think this should cover all bases, and should appear in the next RC or final.