@sam_nazarko I have not received a mailing address to send anything to, however in getting everything ready to throw in a box to prepare to ship to you I realized that I think I left my Vero and HDMI cable in the hotel right after all this happened that second week in August. Luckiiy I found all 3 of the SD cards (Vero 8GB, sandisk 32GB and Sony 64GB (yes the one I didn’t want to remove and wipe … still haven’t had time to reformat it and copy the data back lol)) All of which had the issue.
So I need to ask if anyone else is willing to reach out to sam and ship him their effected Vero, I can send him a effected SD card but I still think it has nothing to do with the SD card.
Sam again thank you for all you do, the reason I bought the Vero was to support your work , anyone upset about their Vero not working properly should buy locked down device meant to be used by iDiots. When I was your age I had could not imagine doing what you have done over the last couple years. I look forward to what you can do as you mature into what you will become. For how many times I’ve been burned on Kickstarter I was thrilled when I actually received the Vero.
Please dont get discouraged by people that dont have anything better to do than spew unproductive comments.
The comments here are not necessarily unproductive and I can completely understand people’s desire to buy a product that simply works and their frustration when it doesn’t. That is what I am trying to achieve with the Vero and I think we will get there, albeit with some slightly rough edges initially. They remind me that there is work to be done and I am doing my best to work out what’s happened here.
Once I can replicate the problem in front of me, I can on the situation. I appreciate your help with sourcing an affected unit.
Get your Vero back from the hotel. We have Android coming to Vero very shortly and it should offer some nice features!
Also just a though would it be helpful for someone run the latest update with noquiet and loglevel=7 ??
Hopefully for us all (me if the hotel still has my vero in lost and found or if I find a 2 year old picked it up and ran off with a treasure and hide it somewhere) that log level will provide some more information now that the above mentioned GPU stall bug is fixed. If its still flashing thru the logs displaying the system clock message please note that in this thread. then if possible snap a photo or video as I failed and never captured that for @sam_nazarko.
The Android Comment makes me very happy BTW I’m looking forward to netflix integration, as I have yet to find a solid kodi netflix combo.
Dont work to hard lol I can read that part of myself in your comments, remember to have a life!!! your only young once enjoy it while your still young.
@sam_nazarko: If you send me the shipping information you did (or didn’t yet) send to @altesean I’ll be happy to ship my vero plus card (minus .kodi folder ) to you.
And I second @altesean’s comment. Remember to enjoy your youth…
@arubislander: I see you are having trouble with CEC, but just to confirm before shipping, after you also having issues booting on the new kernel? Have you since tried the ‘August’ image from Download - OSMC?
Have just tried a fresh install of the August image. Same results. The installer runs on the Vero, but when it is finished and it wants to reboot the system I get the following:
[ TIME ]Timed out waiting for device dev-mmcblk0p1.device.
[DEPEND] Dependency failed for /boot.
[DEPEND] Dependency failed for Local File Systems.
The last few lines of the image installer log (running on Ubuntu Vivid Vervet):
do sep. 3 22:54:52 2015 Image successfully written to device
do sep. 3 22:54:52 2015 Deleting the uncompressed image to save space
do sep. 3 22:54:52 2015 Creating preseeder
do sep. 3 22:54:52 2015 Adding preseed stringd-i target/storage string sd
do sep. 3 22:54:52 2015 Adding preseed stringd-i network/interface string eth
do sep. 3 22:54:52 2015 Adding preseed stringd-i network/auto boolean true
do sep. 3 22:54:52 2015 Writing preseeder
do sep. 3 22:54:52 2015 Running partprobe to inform operating system about partition table changes
do sep. 3 22:54:53 2015 Mounting the first filesystem on /dev/mmcblk0
do sep. 3 22:54:53 2015 Trying to umount before we are remounting and writing the preseed.
do sep. 3 22:54:53 2015 Unmounting /dev/mmcblk0p1
do sep. 3 22:54:53 2015 Running partprobe to inform operating system about partition table changes
do sep. 3 22:54:53 2015 Unmounting /dev/mmcblk0
do sep. 3 22:54:53 2015 Running partprobe to inform operating system about partition table changes
do sep. 3 22:54:53 2015 Mounting /dev/mmcblk0p1 to /tmp/osmc_mnt
do sep. 3 22:54:53 2015 Could not mount filesystem!
The complete log of the install on the Vero:
Thu Feb 13 15:12:20 1908 Starting OSMC installer
Thu Feb 13 15:12:25 1908 Detecting device we are running on
Thu Feb 13 15:12:25 1908 Mounting boot filesystem
Thu Feb 13 15:12:25 1908 Trying to mount to MNT_BOOT (/mnt/boot
Thu Feb 13 15:12:25 1908 Using device.boot: /dev/mmcblk0p1 and FS: vfat
Thu Feb 13 15:12:25 1908 No preseed file was found
Thu Feb 13 15:12:25 1908 Creating root partition
Thu Feb 13 15:12:25 1908 From a root partition of /dev/mmcblk0p2, I have deduced a base device of /dev/mmcblk0
Thu Feb 13 15:12:25 1908 Determined 255 MB as end of first partition
Thu Feb 13 15:12:25 1908 Calling mkpart for device: /dev/mmcblk0 and fs: ext4 with start 257M and end 100%
Thu Feb 13 15:12:27 1908 Calling fmtpart for partition /dev/mmcblk0p2 and fstype ext4
Thu Feb 13 15:12:38 1908 Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=2 blocks, Stripe width=1024 blocks
476720 inodes, 1903360 blocks
95168 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=1950351360
59 block groups
32768 blocks per group, 32768 fragments per group
8080 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632
Allocating group tables: 0/59 done
Writing inode tables: 0/59 done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: 0/59 done
Thu Feb 13 15:12:38 1908 Mounting root
Thu Feb 13 15:12:38 1908 Trying to mount to MNT_ROOT (/mnt/root
Thu Feb 13 15:12:38 1908 Using device.root: /dev/mmcblk0p2
Thu Feb 13 15:12:38 1908 Extracting files to root filesystem
Thu Feb 13 15:12:38 1908 Starting extract progress...
Thu Feb 13 15:14:25 1908 Extraction of root filesystem completed
Thu Feb 13 15:14:25 1908 Configuring bootloader
Thu Feb 13 15:14:25 1908 Configuring bootloader: moving /boot to appropriate boot partition
Thu Feb 13 15:14:26 1908 Configuring boot cmdline
Thu Feb 13 15:14:26 1908 Configuring /etc/fstab
Thu Feb 13 15:14:26 1908 Successful installation. Dumping log and rebooting system
I don’t know what the image installer wanted to do after mounting the first partition on the sdcard. Whatever it was, it couldn’t do it because the mount failed. Could that be related?
Exactly the same fault here, as previously posted by me after the July update. Installed the August update and again, the same thing.
If it was an issue on a Pi I wouldn’t mind, but after having pain £120 odd pounds for the flagship device, its not really good enough to not be able to use if for over a month.
After some investigation, I have an idea as to what the issue may be. I was slightly puzzled by the fact that your Veros are partially booting before stalling. The fact that your device partially boots implies that the initial read from the SD card fails. During the boot, there is a transition to UHS (Ultra High Speed) and I believe that this is failing and is why you are seeing problems. The approach to delay the transition (with mdelay()) is not the right approach, because it seems that the issue is actually caused by voltage.
Currently, in the kernel, we are trying to set UHS voltage to the maximum current the host can provide (1.8v via a dummy regulator). This is not a good idea: clearly some cards have different levels of tolerance. If this fails, then we have a problem. The new approach is to gradually lower the current settings until they are accepted and the transition is successful.
I am currently building a new kernel to hopefully rid those annoying freezes some users were experiencing overnight. The SD card fix is included. Once we are happy with that, the kernel will be pushed as an update. I will then build an image with these changes in so that you can install directly (as obviously, an upgrade is difficult right now).
I still cannot replicate this myself, but fingers crossed this resolves the issue.
First of all, I want to say thank you for all your hard work. Reading your response made me realise with how much passion and sincerity you try your best to make the Vero a leading device.
I will gladly help you solving this awkward dependancies problem by accepting your offer to replace my Vero with a working model. Please contact me through my email so we can talk about the details.
I will have a test image for you which will be available tomorrow. If this doesn’t help then I will send you an email and arrange to get the hardware off of you
Following your instructions, I just tried to install the new kernel on my working June version.
Here is a copy of the log entries:
Running depmod.
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 4.1.6-1-osmc /boot/vmlinuz-4.1.6-1-osmc
run-parts: executing /etc/kernel/postinst.d/inform-updater 4.1.6-1-osmc /boot/vmlinuz-4.1.6-1-osmc
run-parts: executing /etc/kernel/postinst.d/process-vmlinuz-vero 4.1.6-1-osmc /boot/vmlinuz-4.1.6-1-osmc
(Reading database … 24826 files and directories currently installed.)
Preparing to unpack vero-kernel.deb …
Unpacking vero-kernel-osmc (1.6.8) over (1.4.2) …
dpkg: dependency problems prevent configuration of vero-kernel-osmc:
vero-kernel-osmc depends on vero-image-4.1.5-6-osmc; however:
Package vero-image-4.1.5-6-osmc is not installed.
dpkg: error processing package vero-kernel-osmc (–install):
dependency problems - leaving unconfigured
Errors were encountered while processing:
vero-kernel-osmc
Connection to 192.168.178.27 closed by remote host.
To my surprise, after a couple of cold reboots, my Vero booted successfully.
Here is the output of the line you asked for:
osmc@osmc:~$ cat /proc/version
Linux version 4.1.6-1-osmc (root@vero) (gcc version 4.9.2 (Debian 4.9.2-10) ) #1 SMP PREEMPT Tue Sep 8 18:06:43 UTC 2015
After a couple of tests, the system does not run flawlessly, I’m afraid:
Using KODI’s reboot button to restart the Vero will make it shut down, but it does not perform a successful reboot (neither the OSMC boot screen, nor the KODI home screen will show up). Instead the device will not output any video signal. It will only reboot successfully doing another cold reboot (pulling the plug).
After every launch KODI displays the following error message:
“Pulse-Eight CEC adaptor. Could not initialise the CEC adaptor. Please check…”
Can this be the reason for the OSMC remote to now fail from time to time completely, with the on screen highlighter to jump around the screen like mad? (Something which has never occurred before and and yes, I checked the battery and it is fine).
Open the OSMC installer on your computer, select ‘Vero’ and then select Use local image. Browse to the image that you downloaded and follow the setup procedure as you normally would.
Just installed the new image and we’re back to the old dependency problems! Vero not booting, reporting:
Timed out waiting for device dev-mmcblk0p1.device.
Dependency failed for /boot
Dependency failed for Local File System
I’ve got this problem as well. I suspect it happened on the same update but the kids didn’t tell me it had stopped working. The only element I have customised (Vero with factory build that has been updated) is that I set Kodi to use a MySQL library that sits on my NAS.
I’m looking forward to netflix integration, as I have yet to find a solid kodi netflix combo.
) to you.