Please keep me posted, this will help other users
Sam
Hi,
for three attempts was ok, but the fourth showed again the issue.
The logs, as usual, are here:
http://paste.osmc.io/fipicateta
http://paste.osmc.io/vinosaloxu
It seems doesn’t recognise some partitions?
Thanks.
The problem is a timing issue where the disk is not read to read at the time that udisks-glue reads it but we are still unsure what is causing it.
thanks for your explanation but this lines seems tell something else:
Sep 08 22:37:19 osmc udisks-glue[259]: Device file /dev/sda inserted
Sep 08 22:37:20 osmc udisks-glue[259]: Device file /dev/sda1 inserted
Sep 08 22:37:20 osmc udisks-glue[259]: Device /dev/sda1 did not match any rules.
Sep 08 22:37:20 osmc udisks-glue[259]: Device file /dev/sda2 inserted
Sep 08 22:37:20 osmc udisks-glue[259]: Device /dev/sda2 did not match any rules.
when its work whe have:
Sep 09 22:13:44 osmc udisks-glue[304]: Device file /dev/sda inserted
Sep 09 22:13:44 osmc udisks-glue[304]: Device file /dev/sda1 inserted
Sep 09 22:13:44 osmc udisks-glue[304]: Trying to automount /dev/sda1...
At which rules it must match ?
You miss the point - the rules are always the same, and the disk is always the same.
“Device /dev/sda1 did not match any rules.” means that the file system type could not be determined by udisks. As I said, the problem is timing related and prevents the partition being identified sometimes but we don’t yet know what the cause is.
I have just pushed out another diskmount-osmc update with increased log debugging, please update to get it, then when you see the problem happen again please provide the full system journal with:
sudo journalctl | paste-log
Thanks.
Hi, after the last diskmount update I’ve lost my local USB hard disk drive.
Here is the log: http://paste.osmc.io/esedemowes
and here is the recent dpkg log:
2015-09-10 18:02:12 startup archives unpack
2015-09-10 18:02:14 upgrade diskmount-osmc:all 1.3.7 1.3.8
2015-09-10 18:02:14 status half-configured diskmount-osmc:all 1.3.7
2015-09-10 18:02:14 status unpacked diskmount-osmc:all 1.3.7
2015-09-10 18:02:14 status half-installed diskmount-osmc:all 1.3.7
2015-09-10 18:02:16 status half-installed diskmount-osmc:all 1.3.7
2015-09-10 18:02:16 status unpacked diskmount-osmc:all 1.3.8
2015-09-10 18:02:16 status unpacked diskmount-osmc:all 1.3.8
2015-09-10 18:02:16 startup packages configure
2015-09-10 18:02:16 configure diskmount-osmc:all 1.3.8
2015-09-10 18:02:16 status unpacked diskmount-osmc:all 1.3.8
2015-09-10 18:02:17 status half-configured diskmount-osmc:all 1.3.8
2015-09-10 18:02:18 status installed diskmount-osmc:all 1.3.8
2015-09-10 18:02:18 startup packages configure
How can I revert the last diskmount update?
Thank you
Kranz
Thanks for the log file, it helps eliminate a few more possible causes.
Absolutely nothing was changed that would affect whether the drive mounts properly or not, so there is no use trying to revert it - all that was added was one debug command (udisks --show-info) which only runs if the drive already failed to mount.
The problem that we are trying to solve is an intermittent timing related problem (also known as a race condition) so very small differences in timing of the system booting up can cause it to succeed or fail randomly.
Does the drive mount if you reboot from Kodi ?
Yes, it mounts as usual after a reboot.
I have the same problem with mounting my HDD. I connected a D-link powered USB HUB and HDD on it, but I need to reboot device once or two times to RPI 2 recognize it.
Do you have the same issue if you’re not connected through the hub ? Please provide a system journal when it fails to mount, and another one if possible when it does mount so we can compare:
sudo journalctl | paste-log
Everyone in this thread having problems with their drive not mounting in /media on boot, I have a slightly more experimental fix for you to try - I’m not going to push this one out to all users (for now) but focus on testing with only those who are affected. So to download the test build and install it, please run the following two commands:
wget http://apt.osmc.tv/pool/main/d/diskmount-osmc/diskmount-osmc_1.4.0_all.deb
sudo dpkg -i diskmount-osmc_1.4.0_all.deb
You should see a message saying it is updating to version 1.4.0. Then reboot by typing ‘reboot’. If you still have issues with the drive not always mounting every time on boot, (try rebooting a few times and also shutting down and powering back on a few times to make sure it is reliable) please post your system journal after a boot where it failed:
sudo journalctl | paste-log
If it fixes the problem please let us know as well of course!
Also can everyone having this problem confirm that you have a Pi 1 ? Is anyone seeing this issue on a Pi 2 ?
I have Pi 2, as I wrote before.
Will try bug fix next week because momentaly I’m not at home.
Just upgraded to udisk 1.4. Powering on two times, I haven’t the issue.
As usual I’ll try again and again to be sure that it not
happen another time.
And I have Pi 1. I also have a Pi 2, but without Osmc, if you think it could be useful I can check it.
I meant diskmount 1.4, sorry
Thanks for that. Give it plenty of testing. Also if you could provide a copy of your system journal when it does successfully mount on boot that would be helpful - I have put a timer in the startup of the service to see how long it is delayed by udevadm settle, so it would be useful to know how long it is delayed on a Pi 1.
After several days of testing I have not found the issue.
I’m available for any checks, otherwise we can consider this thread as closed.
Thanks
Thanks for reporting back - the only thing is we’re not entirely happy with the way this fix works - it is more of a workaround for a problem whose root cause is not quite understood, so we may be testing alternative fixes to this before settling on one to push out to all users. If we come up with a better way to fix it we’ll post it here if you could test it for us.
Thanks.