After completely nuking my system (again!), I’m trying to restore from a backup, but it wont boot because the kernel is not as expected.
I’m getting an error could not open moddep file '/lib/modules/4.9.35-v7+/modules.dep.bin'
It would be great if you could check your /lib/modules and if you have 4.9.35-v7+ zip it up and email it to me - it will save me having to completely rebuild everything from scratch!
Thanks
Paul
You can download it direct from the Raspian repo
Thanks @Bill.Thomson & @pb66
Unfortunately, having added the file - which was no mean feat as in it’s current state I can’t mount a usb drive, or get network access… now a whole load of other kernel related libraries are shown as missing also, and are showing as errors during boot-up.
If you check your /lib/modules directory, and go into whatever kernel versions files that you have, you’ll see there are a number of files in there, whereas in my /lib/modules/4.9.35-v7+/ directory, I just have modules.dep.bin
It seems that I need the whole /lib/modules/4.9.35-v7+ directory to return to a working state.
I can’t quite understand how this has arisen, as this was a full rootfs backup which was verified.
I suppose I’m lurching towards a complete re-build. 
Paul
Edit - my backup has the directory 4.4.38-v7+
I won’t breakout the old mind-reading cartoon, but “my system” is pretty vague 
Is this an emonPi/emonbase emonSD or a home brew? Are you still using a hdd?
Those files are usually only tampered with during apt-get upgrades, have you had a failed upgrade eg reboot or power outage mid upgrade?
If the file were missing from the backup only (assuming it has functioned properly in the past) it might suggest the backup was run during a transitional state, is it possible an automated backup was triggered whilst an apt-get update was in progress? A bit of late night tinkering whilst a backup was being done by cron perhaps?
Replacing the missing files shouldn’t be difficult if you have a spare SDcard or Pi. Exactly how depends on your hardware setup and what you have to hand. But in basic terms you need to mount the faulty image to a working image and put the files in place using the full “mounted” path.
I just downloaded the full 4.9.35 firmware version from the repo and zipped up just the modules folder for you and put it in a public folder on my dropbox as it’s too big to upload here (Dropbox - modules.zip - Simplify your life) so you should be able to download using
sudo wget -O modules.zip https://www.dropbox.com/s/9ysr0tgsfus914a/modules.zip?dl=0
then you should be able to just unzip into place with something like
sudo unzip -o modules.zip -d /mount/point/lib
changing “/mount/point” to whatever you mounted it as, you will probably need to set/check all the permissions too, all the directories under /lib/modules seem to be 755 whilst the files are all 644 and everything is owned by root:root.
That should reinstate the modules folder but without knowing the cause you won’t know if anything else is broke until you try it.
Was the original reason for restoring a backup related or unrelated? The usual cause for kernel discrepancies is the /boot partition not mounted correctly or at least not mounted correctly at the time an upgrade was performed, if running a hdd setup it’s worth checking your /boot folder is mapping to the /boot partition rather than a redundant /boot folder if the fstab isn’t right.
A bit of a PITA but sometimes it brings some peace of mind when you don’t know how or why it went belly up, or the full extent of the damage.
Success!!
Both @Bill.Thomson and @pb66 emailed me the missing 4.9.35-v7+ files which have worked great, restoring my system.
I didn’t mind starting afresh (with the new raspbian stretch OS) but I really, really didn’t want to have to set up everything that accompanies it, such as apache & node-red SSL certificates, 2 websites, scripts, backup routines etc, etc.
Both of you have saved me a lot of time & effort, and I am really grateful, thanks you.
Paul
Now it’s time for a
