Dependancy failed for local file system. After July update

Does the July update install though? The installer runs the same 4.x kernel so if you can get that far, it suggests that something could be problematic with the card.

Can you take a photo of the back of the card?


The installer boots from the fat partition and runs thru the install like it’s working but never formats the card like it should.

It just seems odd that it works perfectly under kernel 3.14 but then fails under 4.1

Do you receive an error? What makes you believe the card is not formatted correctly?

This is an issue that has peaked my curiosity, mainly because you say the new kernel breaks it. Does it work for a considerable amount of time on 3.14?


I say that because it did not create the second partition on the SD card that it normally does. The install log looks perfect with no errors…

On 3.14 it works continuously with no issues, no crashing and no freezing.

Hi. I am encountering the exact same problem on my Vero after the July update. But, since I have tried Sam’s installation/update path on two different Sandisk 8GB Ultra cards, I suppose we can rule out an SD-card as the source of it. In both cases, the June update, which I installed using the image file and the OSMC-Installer on my Mac, works like a charm. Then, updating to the July update (choosing manual update from the gui) results in the described dependency failure after each reboot and a non operable device. Btw, the July installation process completes with no errors and displaying 100%. After that, it automatically reboots my Vero. Have not tried the older kernels. If needed, I can provide screenshots and logs.

I have been unable to replicate this on SanDisk cards which we ship out myself, which is frustrating.

I have an idea, and I’d appreciate it if you could keep the (failed) July installation aside and try a fix for it in an an hour or two.


Just let me know I’m willing to help in any way.


Try this:

  • Install the June version and then update to July. Don’t try and install the July image directly as we’ve no guarantee in your circumstances that the update is being fuly installed properly
  • Replace zImage and imx6dl-vero.dtb with the following versions after the boot starts failing.


I’ll give it a try when I get back home tonight.

Same results with the new files…

After replacing both files, I now don’t even get the OSMC boot screen, but instead only get a black screen. Booting with the other SD-Card and the June update, the Vero starts up fine.

Any progress?

I’ve not been able to replicate this issue locally, so I haven’t the foggiest what it can be. I haven’t heard of any other complaints on the OSMC forum either which strikes me as odd. It would be interesting to see if your Vero worked with another SD card on this new kernel


I sent you a email last week to sales as you requested however I have not heard anything back yet. I did go out and buy a new micro sd card today and I will update you on the results in a little while.


Same results with a brand new Sandisk extreme Plus 32GB micro SD card.

I REALLY didn’t want to but I pulled the microSD card out of my phone and I’m backing it up right now just to try a third sd card.

Hi Sean

I got your email – didn’t reply as I assumed we could pursue it via this thread. However, I do now have your details and if we can’t get it resolved by Thursday I’ll just ship another card. Although I doubt there is much issue with the card, a new one may be the best idea if we can’t resolve it.

Is your third SD a non-SanDisk one?

This sounds like a very odd SanDisk issue.


Third was a Sony 64GB micro SD card and again the exact same results… looking like a vero issue at this point.

I got the same problem after July update.

My Vero booted as normal again after changing to the old files.
I’m using the original micro SD card.


It seems the SD card is not the issue then, but that this is a software related issue.

Unfortunately I am still having issues replicating this.

It would be good if you could edit uEnv.txt on the SD card and change the following arguments:

“quiet” to “noquiet” and loglevel=2 to “loglevel=7”.

If you can make a video recording of the bootup we may be able to see the issue