RPI2 initrd corruption after november updating

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 in advance for your help, the logs:


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)

This problem has been fixed in this commit:

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.

I have this issue as well, how do I apply the update if my device will not boot due to this? Do I have to completely reinstall?

Actually never mind I have a different problem.
It now says “cannot mount ‘root’ of ‘filesystem’”
“can’t access tty: job control turned off”

  • Rename the latest vmlinuz-4.2.3-* file to kernel.img
  • This will allow you to boot. In a few hours, an update will be available which resolves this issue. We will update this post.



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.

Yes sir, I did it.

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.

PARTUUID is deprecated.

Use UUID now which is better. Run sudo blkid on your volume to get the UUID


If you check for OSMC updates you should find another kernel update that fixes this issue. Give it a try and let us know if it fixes it for you.

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

So, can I modify this parameters:

$ cat /boot/cmdline.txt
root=/dev/sda5 rootfstype=ext4 rootwait quiet osmcdev=rbp2 rootdelay=5

And use UUID=XXX… instead /dev/sdaX?

Done. This works fine for me, you are awesome!

Hi there

Prior to installing the November update I had the below in my cmdline.txt file and could boot fine via my USB install of OSMC.

root=PARTUUID=00072d57-01 rootfstype=ext4 rootwait quiet osmcdev=rbp1

After having applied the November update however I have had to revert to using this in order to boot.

root=/dev/sda1 rootfstype=ext4 rootwait quiet osmcdev=rbp1

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.

@Liad @hewittj:

I have an initramfs for you to try that should fix this problem. You can download it from here:




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.

1 Like

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:

  1. Downloaded the rbp1-initramfs.gz file

  2. Renamed it to initramfs.gz

  3. Copied it to the boot partition on my SD card

  4. Added the line initramfs initramfs.gz followkernel to my config.txt file

  5. Changed my cmdline.txt to use root=UUID=XXXXXXXXXXX

  6. Booted the RPI and received the below

What did you use to download the file ? Di you use wget on the Pi or did you use a browser on a PC / Mac - if so which browser ?

Make sure the file did not get automatically unzipped during download - this is something that Safari does by default for example.

Downloading directly to the Pi with wget is the best approach.

Also remember the file is case sensitive - it should be all lower case when renaming it.

I’ve found a problem with the rbp1 version of the file, sorry about that. I’ll update the download links shortly.


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