Dependancy failed for local file system. After July update

Sam,

Firstly, great work.

I’ve got the same problem (on a Rev 1 Vero with the original card). Have you got hold of a failed machine to be able to do the testing/diagnostics? I’m going to revert back to the June image until this is sorted so do let us know when we have a proven solution.

Yours, Tom

Sam,

Have you been able to make any progress on the issue?Can I expect a solution pretty soon? If not, I would ask you to e-mail me so we can start the replacement like you suggested before.

Adrian

Sam,

Do you have an update on the issue? I know you have a lot on your plate but am concerned that I will be left in a frozen position with no ability to update my Vero.

Yours, Tom

Hi

Have you tried the latest Vero image? 2015.09-1.

Sam

I hadn’t after Adrian indicated that he had the same problem with that image (his post of Sep 16 and Sep 22).

That image was only released last night, so I don’t believe anyone here affected has tested it yet

Sam

OK. I’ll give it a try tomorrow. Thanks, Tom

Sam

One week ago, I ask you to e-Mail me so would could start the hardware exchange you offered to me weeks ago.
Still, not having received any e-mail or message from you, I now find that yet another image has been posted two days ago. I find this lack of communication quite irritating.

Anyway, I have just tested this brand new image (2015.09.-1).
And surprise, it does NOT resolve the problem at all!

For more than a month now, I have shown a lot of patience and although not being part of your team of beta testers, I have tried to assist you in solving this problem any way I could.

Since you claim that this crucial problem only affects a minor number of devices, I really don’t understand why you still have not offered a recall for those Veros.

As an early adopter, I was willing to pay you around 200€ for a device completely unknown and untested!
Like tombertie, I now am concerned that you will leave us in a frozen state with no ability to update or resell our Veros.

I regret to say, but I am beginning to lose faith in the product, because of the lack of efficient support.

Once again, I ask you to exchange my Vero for a working, new and unboxed model at no additional costs, asap.
Otherwise, I see no other possible option but to return my Vero and demand a full refund!

Adrian

Hi Adrian,

I have read your series of edited post tonight, and it gives me an insight in to your frustration, which I completely understand.

First and foremost, we were (reasonably) confident we could resolve the issue you had. The fact that it presented only under certain versions of OSMC indicates that this is indeed a software issue. However, no one on the team has been able to replicate it nor have we had any logs to indicate the cause of the problem. We reached out last month to some users to get a return where this issue is replicable but this fell through.

It’s time to get a unit off of someone affected. If you send me an email with your details (sam@osmc.tv), I’ll
give you the details to return it. I can’t guarantee the issue will be resolved when it comes back to you (we lack detail on your environment), but I can promise I will test every possible cause and see if I can retrieve any clues from your SD card. I have a better chance of replicating the issue with the device in my hands than remotely. Did you every try an alternative SD card, and did it provide any benefit? Of course, we are happy to swap your Vero, but we need to make sure that doing so will actually benefit you, and not leave you disappointed due to an environment specific issue that is affecting you.

I have replied as quickly as possible and I am happy to answer any questions you have and receive (and fix) your Vero. Please let me know how I can further assist you. I want the best for you and for this issue to be fixed as quickly as possible.

Cheers

Sam

Hi

Updated my Vero with september update, but dependancy is still failing.
Back to 3.14 kernel again…

I have tried that image and it throws the same error straight away. This is now preventing me from updating the other KODI instances that I have around the house, as they use the same database for the library. While the fault only exposes itself in certain versions of OSMC, the fact that it only appears to affect early versions of hardware suggests a hardware problem. I am also starting to have my patience tested, much like Adrian.

I am waiting on a customer to send back their unit.

Do you have multiple units to show this? This would be very helpful in diagnosing the issue. We are going through SD card commits and working on trying to find out this issue, but without a log or access to any hardware affected, we can only guess.

Cheers

Sam

All I have it was I see myself and in this forum, as follows:

  • Mine worked fine until the Jul update and continues to work with previous images => it is either a software issue or a hardware issue that is exposed on particular software conditions
  • Your update in July would appear to work for most of your customers as there are only a few of us complaining => this is a hardware issue that is exposed on particular software conditions
  • Others on this forum indicate that, like me, they were early adopters with Rev 1 models => there may be a small number of an early batch with the fault.
    It is only a hypothesis, but difficult to see evidence that would point more strongly to other scenarios. If you are able to send me a replacement model I’ll send you mine back (it is currently the media centre for my childrens’ playroom, so I’d rather no lose the capability as a result of me sending it to you first). How do you propose we proceed?
    Tom

If you get in touch with sales@osmc.tv and send back your model we can indeed ship a replacement SD card or Vero (whichever is needed to resolve the issue)

Sam

Sam,
Today I tried version 2015.09.-2 : same issue.
I’m really frustrated being stuck to version 2015.06 with no other solution than sending both Vero and SD card back to you, leaving me with no other hardware for my Kodi setup.
I have ordered an Amazon Fire TV gen2 that i should receive next week. If it arrives has advertised i’ll send my Vero back to you for your tests. Can you confirm you will cover shipping costs please.
Best regards,
Xavier

Hi

We can cover the return postage if we find an issue (which we no doubt will)

Sam

Hi

We have still been looking at this. @DBMandrake was experiencing some instability in our latest kernel, and we seem to have made some headway with this. The changes involved some SD card commits, so maybe this will help.

The next step will be to add mmc_debugging.

Does the image (September), still boot and go far enough that it installs for you? I’ve been wondering why it works for first boot, but then doesn’t after that, when the same kernel is being used. I’m now starting to wonder if perhaps the OSMC Installer isn’t writing the data to your SD card properly.

Can anyone experiencing this issue plug the SD card after installing upload the installer.log file from the FAT32 partition?

Sam

Just tried again with a clean Sept v2 image. The output from the installer.log is as follows:

Sun Nov 29 19:41:40 1903 Starting OSMC installer
Sun Nov 29 19:41:45 1903 Detecting device we are running on
Sun Nov 29 19:41:45 1903 Mounting boot filesystem
Sun Nov 29 19:41:45 1903 Trying to mount to MNT_BOOT (/mnt/boot
Sun Nov 29 19:41:45 1903 Using device.boot: /dev/mmcblk0p1 and FS: vfat
Sun Nov 29 19:41:45 1903 No preseed file was found
Sun Nov 29 19:41:45 1903 Creating root partition
Sun Nov 29 19:41:45 1903 From a root partition of /dev/mmcblk0p2, I have deduced a base device of /dev/mmcblk0
Sun Nov 29 19:41:45 1903 Determined 255 MB as end of first partition
Sun Nov 29 19:41:45 1903 Calling mkpart for device: /dev/mmcblk0 and fs: ext4 with start 257M and end 100%
Sun Nov 29 19:41:47 1903 Calling fmtpart for partition /dev/mmcblk0p2 and fstype ext4
Sun Nov 29 19:42:00 1903 Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=2 blocks, Stripe width=1024 blocks
469568 inodes, 1877760 blocks
93888 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=1925185536
58 block groups
32768 blocks per group, 32768 fragments per group
8096 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632

Allocating group tables: 0/58 done
Writing inode tables: 0/58 done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: 0/58 4/58 done

Sun Nov 29 19:42:00 1903 Mounting root
Sun Nov 29 19:42:00 1903 Trying to mount to MNT_ROOT (/mnt/root
Sun Nov 29 19:42:00 1903 Using device.root: /dev/mmcblk0p2
Sun Nov 29 19:42:00 1903 Extracting files to root filesystem
Sun Nov 29 19:42:00 1903 Starting extract progress…
Sun Nov 29 19:43:56 1903 Extraction of root filesystem completed
Sun Nov 29 19:43:56 1903 Configuring bootloader
Sun Nov 29 19:43:56 1903 Configuring bootloader: moving /boot to appropriate boot partition
Sun Nov 29 19:44:04 1903 Configuring boot cmdline
Sun Nov 29 19:44:04 1903 Configuring /etc/fstab
Sun Nov 29 19:44:04 1903 Successful installation. Dumping log and rebooting system

I hope this helps

Tom

Let me know if you want any other artefacts, such as cmdline.txt for instance

Tom

That looks successful to me, so I’m still at a loss as to what the cause of the problem can be.

Sam