I am unable to boot from a Ubuntu Live USB stick (current version 20.04 LTS) whatever I try. The boot stops right after the "disk check" completed successfully. When booting without the splash screen (nosplash), I get the following message:

run-init: can't execute 's/sbin/init': No such file or directory
Target filesystem doesn't have requested /sbin/init.
run-init: can't execute 's/sbin/init': No such file or directory
run-init: can't execute 'etc/init': Permission denied
Kernel Panic - not syncing: Attempted to kill init! exitcode=0x00000100

Kernel panic

enter image description here

Since the boot does not get me even to a command line, I cannot provide a log as text file. However there is a video of the entire boot process. If you think that helps, I can put that somewhere.

I have been researching for days and believe to have tried every last thing that was suggested in any post I could find. Here is a list of all the things I've tried, not necessarily in chronological order:

  1. Verified downloaded ISO successfully (SHA256 as provided here)
  2. Tried three different USB sticks, two USB 3, one USB 2, each of which was set up multiple times with the latest version of Rufus (3.10).
  3. Tried different USB sockets on the computer, from both of the two USB controllers which the mainboard has.
  4. Played around with the few options my Bios offers regarding booting (e.g. UEFI vs. Legacy+UEFI, Support for Win 7/8 installations on/off, secure boot)
  5. Updated BIOS
  6. Tried booting with UEFI and non-UEFI
  7. Tried all these advanced boot options: nosplash, nomodeset, acpi=off, nolapic
  8. Disconnected everything from the computer other than Live USB stick, keyboard+mouse dongle and screen
  9. Checked that my hardware is supported, which seems to be the case for the (presumably most important) Intel Z170 chipset

My computer:

  • MSI Z170A Gaming M5 (MS-7977, specification) (I'm not a gamer, but this model ticked all my boxes at the time...)
  • Intel Core i7-6700 CPU (3.40GHz)
  • Corsair Vengeance LPX 2x8GB DDR4
  • Should not be relevant, but there's a Samsung SSD 950 M.2-drive inside, which houses Windows 10 (which always has been and still is running without issues)

I just don't understand how the kernel (?) cannot access files from an image that it has (presumably) either extracted into memory just a second earlier or at least successfully checked for integrity the moment before. What am I doing wrong??


Since you can boot in UEFI mode, let's take Rufus out of the equation:

What happens if you just format one of your drives to FAT32 (you can Windows Disk Manager to do that, whether the drive is GPT or MBR does not matter), then manually extract all of the ISO files onto that drive (you can uze 7-zip to do that) and then attempt to boot it in UEFI mode?

Considering that this is pretty much what Rufus does when creating a UEFI drive, I expect that you will see the exact same problem.

The error you get is quite puzzling because if the ISO SHA256 matches and especially the file validation of /casper/filesystem.squashfs did not produce any error, then /sbin/init, which is definitely present on the SquashFS filesystem, should be accesssible.

The only things I can think of are:

  • Weird bug with the handling on symbolic links, since /sbin is a symbolic link, for SquashFS for certain types or underlying file systems (but that's unlikely because there's really nothing fancy about symbolic links)
  • Weird SquashFS decompression bug, since SquashFS uses compression, where the underlying file system could have an effect when the SquashFS driver requests additional file blocks for decompression, and decompression might use some specific CPU extensions for speed (which would explain why it would be limited to only some platforms).

Another test that might be worth conducting, is to try with a FAT32 formatted drive and add toram to your kernel options (the ones where you added nosplash), so that the SquashFS image is loaded to memory and read from there rather than disk. If you do that, you should see that the boot process takes longer with a message like Copying live-media to ram.... This should help confirm whether this really has to do with FAT32 being used as the underlying filesystem for the SquashFS file.

  • This issue has gotten even stranger. While going through your suggestions, I suddenly found that I was not able to reproduce this error any more at all! The same things I did dozens of times (same ISO file, same Rufus, same USB sticks, same computers), which all yielded the same error, now all went the way they were supposed to. One the one hand I'm glad, of course, but at the same time this leaves me uneasy, since I don't know what could possibly be different now from a few days ago. Obviously something is, though! I'm sorry for having wasted everyone's time! – Marco May 18 '20 at 16:41

It turns out to be an issue with the USB stick after all. Two things I had not tried previously proved to work:

Either writing the ISO image to the USB stick in DD mode. (Rufus offers two different modes of writing the ISO image to the USB stick: ISO mode and DD mode; ISO mode is standard.) This has the disadvantage of not being able to use that particular USB stick for anything else.

Or formatting the USB stick as NTFS (instead of FAT32, which is most often used for USB sticks)

What I could find in the Rufus FAQ seems to suggest that the ISO has issues to start with (missing FAT32 module support in the GRUB EFI bootloader, according to the Rufus FAQ).

Edit: Pete, the Rufus developer, has taken an interest and we are investigating what might have happened here. It does not seem to be a widespread issue, though. I will report back.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.