Installing to a disk doesn’t give the benefits that it used to; and a rotational disk could suffer from performance issues.
Do you have another disk you can try with? Could you let me know more about the disk’s capacity?
Sam
Thank you Sam,
I’ve just figured out that by typing ls -l /dev/sda1 instead of sda on the end it tells me it can see sda1 the result is: brw------- 1 0 0 8, 0 Jan 1 00:00 /dev/sda1 so I guess it’s failing to mount sda1
The hard drive is a Western Digital 160Gb AV Drive designed for streaming video without bad performance hits. It’s connected to the Pi using a IDE to USB adapter.
What I don’t understand here, is why it would mount under version 2018-01 with no problem, and not mount under version 2018-04 If you can help with that then i would appreciate it.
Thank you again!
EDIT:
I’m sort of getting the hang of the ls command now… and changing directories etc etc… I cant actually find an OSMC directory anywhere… I’m guessing this means that there are files missing. And not just a few files. We seem to have a basic OS installed… but nothing else, and the boot files don’t appear to be on the Hard Drive… which would explain why it’s saying “Could not find root filesystem device /dev/sda1” I don’t know if this information helps any.
The current environment is an initramfs
The OS is on the drive but isn’t being mounted for some reason. As you’re using a USB -> IDE bridge I’d chalk this up to some timing issues.
Can you type dmesg and post a photo of the output?
I can do that if you want, but It might not be very readable… It’s also a very long list that scrolls right off the screen is there a way to page the output so that I can photograph it in sections, or is it possible to dump the output to a file on the SD Card, that would be easier to get at??
EDIT:
Typical! just when I need it the camera battery is flat… (and i don’t have a phone with a camera on it) OK give me an hour for the battery to charge and I’ll try and get a good photo for you. Looks like the info you need is at the very end of the dmesg file anyway, because it seems to show the Bridge and the Hard Drive there.
Hi,
Please issue the following command:
dmesg | paste-log
And post the link provided.
Edit sorry forgot you were stuck in the rescue console
Thanks Tom.
Hope that helps Sam! If you need a further photograph or any other information I’ll do whatever I can.
Thanks Again!!
Shows the disk is only picked up after 30 seconds. Did you just plug it in then or is the spin up time that slow?
Neither of those is the case… It certainly doesn’t take that kind of time under 2018-01 …
The first 15 seconds is maybe that delay that you had me put in there? I don’t know. I’ll try making the delay 40 seconds and see if it boots.
I’ll report back after that. Thanks!!
EDIT:
That made no difference to the result… it looks like it spends 30 seconds looking for it, finds it, then says it can’t find it. During that 30 seconds, it is occasionally flashing the access light on the drive… so it is trying to see it.
Second Edit:
I’ve just discovered by looking at the contents of the SD card that adding rootdelay=15 or =40 is irrelevant… Because every time it boots, it removes it and reinstates a file without the rootdelay in it.
Third Edit: another thing to bear in mind is that it doesn’t have any trouble finding the hard drive on first boot, to format and install files on… only on the re-boot does it fall over.
Make sure you are unmounting the SD card properly.
Your screenshot shows that the disk is only detected after 33 seconds of uptime.
Unfortunately I don’t have any further suggestions. I can’t reproduce an issue with USB drives here, but I’m not using an IDE bridge.
Such a bridge will almost certainly give worse performance than using an SD card anyhow.
OK thank you for looking at this Sam.
It only doesn’t find the drive for that huge amount of time, since version 2018-02… prior to that no problems at all. Performance even via the bridge, is more than fast enough for 1080p video. I don’t use 4K
So right now, unless somebody knows and understands what changed in the boot between 2018-01 and 2018-02, I have three options… I’m either stuck using the 2018-01, or I install 2018-04 on an SD card and then copy the file system over manually and go through the tortuous process that we used to have to do 4 years ago to get things to run on a USB drive by figuring out which files to manually point at the hard drive. Assuming that there are still any tutorials out there on the web for doing that. Or alternately I move to a distribution other than OSMC which I really really didn’t want to do.
Thanks again for your time Sam. Pity we couldn’t figure out what the actual fault is.
You want to learn? I have a present for you 
Here is a cheatsheet and some tutorials for how to navigate in a Linux shell: Cheatsheets and Tutorials for users new to Linux based operating systems
That won’t work.
The files are on the drive, but initramfs can’t mount the drive in time. It’s unclear why. Copying the files over manually wouldn’t help, but you’re more than welcome to try.
If you really need to boot from a USB drive, you may have to use another distribution. I’d advise against using OSMC on a USB Drive. If you ever reinstall OSMC, your entire disk is formatted. This means if you have a media library, you’d lose that every reinstall unless you backed up.
It’s better to use OSMC as intended for Pi: SD card for OS; and an HDD for any optional storage. I’d also be interested in knowing if the disk is detected and automatically mounted after booting as it should be when attached.
I’ve tested with a few drives here tonight but haven’t been able to reproduce this. If it’s a widespread issue I’m certain we’ll get some other reports here.
Good point Sam… I’ve just run a stopwatch against the boot time in 2018-01 and 2018-04 it seems it’s exactly the same time before they see the drive. about 32 seconds. initramfs then mounts the drive in 2018-01 and continues with the boot. but in 2018-04 it sees it and then doesn’t mount it… very odd!! but at least that gives us a clue as to where it’s falling over so I hope that’s of interest.
Yes… that’s a good point as well… I’ll do that as a test this morning and report back here for you. If it helps with anything then it’s worth me doing it.
Thanks Again for all your time and the work you put in to OSMC.
YUP!! Sees it and mounts it as /dev/sda1… which makes it even more weird that the boot sees it fails to mount it and then says it can’t see it.
OK… I came to the conclusion on this, that continuing to use 2018-01.1 is the best solution for now… For several reasons. Primarily that it doesn’t fall over with my hard drive attached to it and the OS booting from it. But also, because the OS at 2018-01 isn’t falling over anything more than it usually does. On top of which it’s still Kodi 17.6… so no actual change there. And with the hard drive attached, and running the OS from it allows me to set an advancedsettings.xml file with:
<buffermode>1</buffermode>
<memorysize>0</memorysize>
<readfactor>10</readfactor>
Which then caches all the file reads and writes and all stream data limited only to the drive size.
Contrary to belief, that does in fact improve performance fairly significantly inside Kodi. over and above the performance of running it directly from the SD Card, Especially on a lower bandwidth internet connection… With those set it also means that I’m not constantly banging read write operations onto a stressed SD Card, that are not designed to cope with that number of heavy read writes.
So for those reasons Sam. I’m sticking with 2018-01.1 for now. Unless of course you can figure out why all subsequent versions of the base OSMC refuse to see the hard drive.
Thanks anyway for looking at it, and thanks for all the work you do on OSMC. If there is any other information I can provide you that will help, don’t hesitate to ask.
Edit:
P.S. Do we think that this could be related to the kernel issues (sound drop outs every min or so) that have also appeared since the kernel was updated. I noticed those almost straight away on internet streams, when I did have 2018-04 on the box. Didn’t realise that was a known and ongoing issue until I spotted the other thread this morning! Until all this is fixed, there’s absolutely no point in me moving from 2018-01
If you choose to cache to disk, then using an external disk will reduce the read-write load on the SD card, but you seem to be starting from the false premise that it’s better to cache to disk / SD card, whereas in fact it will always be more efficient to cache to memory.
Absolutely… I agree with you, but I sometimes cache two or more hours of HD video when I’ve either got a very slow source or my own internet connection is running at the speed of the average slug. The Pi would have trouble doing that in memory. Some days it’s OK some days it’s not. I’m on an absolutely atrocious rural uk internet connection.