Device: Rasp Pi 2,
Installation media: SDcard, USB Hard Drive
Connection: Wired
Power Supply Type:
Power specs: 5V 200mmA
Storage: Seagate 5T USB hard-drive
Peripherals: USB Hard Disk, Bluetooth Logitech Keyboard K400r with bluetooth dongle
OSMC version: VERSION_ID=“2015.11-1”
Hi guys,
sorry for bothering only when I have a problem but everything has been working fine untill today updating.
So when OSMC updated and configured the new kernel, I received an alert which said the system was unable to generating the initrd because it didn’t find the drive /dev/sda5 where is actually installed OSMC.
Now when I turn on or restart OSMC I have a screen where ext2fsck and OSMC initrd tell me that they are unable to fix the filesystem because /dev/sda5 doesn’t exist thus the system takes 30 seconds to restart and then OSMC starts corretcly.
Is there any way to fix the initrd, can I fix it launching OSMC from the SD card and usig the fsck tools?
Thanks for reporting this. It’s not corruption - the initramfs apparently can’t find the external drive. We may need to load USB modules or add device nodes in the initramfs to be able to read the disk. Don’t worry about trying to fix it yourself, if it still boots ok hold tight and we will push out a kernel update when we have fixed this.
By the way, how did you end up with /dev/sda5 as your root file system on a usb install ? As far as I know the OSMC installer will only install a single partition on the external drive for a USB install thus it would be /dev/sda1. Did you “manually” migrate an install to an external drive containing other partitions ?
FYI, I also notice you have put max_usb_current=1 in cmdline.txt - this will not work, this option should be in config.txt, as it’s an option read by the Pi’s GPU firmware, not by the linux kernel. (Linux is completely unaware of the USB power boost option its all handled in the Pi firmware)
It will be pushed out when it has had sufficient testing. Basically we were not waiting for a slow to get ready device to appear before trying to fsck or mount it.
In my own testing a USB thumb drive takes about 3 seconds to appear and a 2.5" spinning disk (WD Pi Drive) takes about 8 seconds. The script now waits a maximum of 30 seconds for the root device to appear and continues as soon as it sees the device.
Can you take a photo of the errors on the screen and start a new thread of your own to post them in - the issue described in this thread of not waiting long enough for the drive will be unrelated.
I copied manually the partition from the SD to USB HD, however I wasn’t been unable to use “PART-UUID” to recognize the usb drive partition at the boot so I used /dev/sda even if it is not the best solution.
By the way many thanks for fixing the issue and for your advice, I appreciated.
Unfortunately, the latest update seems to have broken booting with UUID. The boot process waits and then fails when it can’t find device “UUID=xxxxxx”. This worked for me on the November update before the last hotfix.
System boots just fine with root=/dev/sda1
When using the line including a PARTUUID reference I receive on-screen waiting for root filesystem followed by a delay and then an error that the root filesystem can’t be found. During this time my USB drive is connected and shows a solid blue LED indicating no disk activity is taking place.
Does anybody have any suggestions about how to restore the ability to boot by referencing a specific USB drive?
Having read through the above I tried using UUID but received the same error as when using PARTUUID in my cmdline.txt file.
I did try renaming kernel.img as mentioned above and this restored the ability to boot using PARTUUID however I’m guessing this isn’t a great long term solution.
Checking for OSMC updates via the GUI shows there are no updates available and I wasn’t 100% sure if the fix for the boot via UUID issue mentioned above by DBMandrake as being available would have been included in an update I carried out a few hours ago?
Apologies guys, I overlooked UUID detection when writing the wait for root device commit above. UUID will need special case handling within the initramfs. I’m looking into how to fix this without reverting the wait for root device changes and will report back here when I have something you can test.
Download this file and save it in your /boot partition named as initramfs.gz
Then edit your config.txt to include the following line:
initramfs initramfs.gz followkernel
This will tell the kernel to use this external initramfs instead of the one built into the kernel image. Then edit your cmdline.txt/uEnv.txt to put back your root=UUID option. This should fix the issue with UUID detection. Please let me know if this works for you.
This fix will be included in next months kernel update so please remember to remove the initramfs line from your config.txt after updating to next months (December) release so that you don’t inadvertently continue to use an out of date external initramfs.
Also please take care not to enter the Pi config and overclock modules in My OSMC as it will remove the initramfs line from config.txt. (It doesn’t currently understand options without an equals sign) If you do by accident, edit config.txt to put it back before rebooting.
Hey @DBMandrake thanks for the update however after following those instructions I receive the attached error when booting my RBP1. Did I go astray somewhere with the instructions maybe? I did the following:
Downloaded the rbp1-initramfs.gz file
Renamed it to initramfs.gz
Copied it to the boot partition on my SD card
Added the line initramfs initramfs.gz followkernel to my config.txt file
Changed my cmdline.txt to use root=UUID=XXXXXXXXXXX
Edit: having some difficulty building the Pi 1 version of this external initramfs, it might be best for you to go back to using the device node name for root until next months update, but rest assured that this problem is fixed and its good to see the report of success from @Liad
