I tried to install Fedora-Workstation-Live 28 from USB, at the start of the Installation as I choose [Start Fedora-Workstation-Live 28] I get the following error. Any solution?

[1.81660] ---[end Kernel] panic - not syncing: VFS: unable to mount root fs on unknown-block(0,0).

(Sys: Lenovo z51 70 - OS: Linux, Ubuntu 18.04 - kernel version: 4.15)

the following errors happened:
as i selected the [Start Fedora-Workstation-Live 28]: as i selected the [Start Fedora-Workstation-Live 28]

as i selected [start this media & Test]: as i selected [start this media & Test]

i changed the USB and got the following errors:

as i selected the [Start Fedora-Workstation-Live 28]: as i selected the [Start Fedora-Workstation-Live 28]

as i selected [start this media & Test]: as i selected [start this media & Test]

  • 3
    How did you create the install media?
    – kemotep
    Jul 3, 2018 at 17:35
  • 1
    @kemotep with dd command, iso file. Jul 3, 2018 at 17:43
  • 1
    The specific hardware/BIOS can sometimes affect things. It could be good practice to name your computer (the brand name and model number), just in case other people noticed it has the same problem. The other specific detail I would provide if I asked this question, is: is this originally a windows 8 or windows 10 computer, and have you left Secure Boot enabled? If so it would suggest you used the newer EFI boot, not the older MBR boot. The two paths are quite different when considering the early boot process.
    – sourcejedi
    Jul 3, 2018 at 18:42
  • @sourcejedi yes there is another option [Test this media and start],i tried it and got the same error but the last line was not the one in the question, i guess it was a hex address.I will edit the question for more info. Jul 3, 2018 at 19:40

2 Answers 2


Solved. obviously the problem was from the USB so i tried to format the USB again with this command:

sudo dd if=/dev/zero of=/dev/sdb

then burning the .iso file on it. now it shows the installing page with no problem.

  • Yes, please consider that this USB may be failing. I.e. if you use the USB to store any important files, you might risk losing them. Or whatever you use it for, it might fail and take you a long time to work out what the problem is, like it just did :).
    – sourcejedi
    Jul 4, 2018 at 11:43
  • Readers, please be aware that on some systems, this specific command will "format" (completely overwrite) an internal hard drive instead. Take great care when specifying the of= parameter. In theory there should be no reason to overwrite with zeros first - it should be just as effective to write the Fedora-Workstation-Live 28 to the USB a second time, without zeroing the drive first.
    – sourcejedi
    Jul 4, 2018 at 11:57

Table of contents

  1. Please use a method of writing to the USB which re-checks the written data. This is probably quite difficult, sorry.
  2. How to verify using cmp command after dd.
  3. The initramfs read from your USB is damaged.
  4. Why I blame the initramfs read from the USB.

1. Please use a method of writing to the USB which re-checks the written data. This is probably quite difficult, sorry.

You are having boot problems that look very much like bad data on the USB. Therefore, please use a USB writing method that re-checks the written data.

dd on its own, does not re-check the written data. Please re-check the data manually using cmp, by following the exact instructions in the next section. Unfortunately I couldn't think of any easier method.

  • GNOME Disks can be used to write a USB (the Fedora install instructions tell you how). But it doesn't seem to re-check the written data.

  • The official Fedora install instructions "default" to Fedora Media Writer. At least the version of Fedora Media Writer I have, does automatically re-check the written data after writing it to the USB. I don't know an easy way to install Fedora Media Writer on your Ubuntu OS :-(.


  • Ubuntu's "Startup Disk Creator" did not work at all for me. I think it is only willing to write Ubuntu ISOs, not Fedora ones.

2. How to verify using cmp command after dd

In principle this could be a simple cmp command. Very sadly, there are some difficulties that will return useless results, so I need to explain these.

I believe cmp might also show differences if you ever allowed the written USB to be mounted on a Linux system :-(. This is likely to happen if you ever plugged it in again to a Linux system after writing it! (Or successfully boot the Fedora Live USB??) You have to be careful with it!

So you want to run dd to write the data, and then cmp command to verify the USB data, without re-plugging the USB (or rebooting) in between.

First run your dd command. Remember to take great care and don't wipe your internal hard drive :).

Then remember you should run sync, to make sure the data is finished writing.

Then, you will be able to run echo 3 | sudo tee /proc/sys/vm/drop_caches. This step is required, to make sure that cmp won't just be reading back from caches in system RAM.

Then you can run

# cmp Fedora-Workstation-Live-28.iso /dev/sdb

I.e. where sdb is the name of your USB device, and the .iso file is the name of your ISO file. This command could show IO errors, or differences, if the problem is that your USB stick needs replacing.

In principle you might want to go further, and test the USB keeps its data correctly after it is removed and loses power. So this would require an alternative method which disables the auto-mount of your graphical login. It can be very hard to know how to disable auto-mount temporarily :-(. I think the simplest way is to log in on a text console and run your commands from there. Make sure you do not switch back to a graphical login before you have finished! For some information about logging in on a text console, see here.

3. The initramfs read from your USB is (probably) damaged

From the evidence so far, it looks like the initramfs read from your USB is damaged. You could try to verify the USB data, on the same system that you wrote the USB. This could be useful to confirm some sort of problem writing to your USB.

For completeness, the full list of possibilities is :-

  1. a problem with writing to your USB
  2. a problem in the ISO image you wrote to it
  3. a problem in your computer e.g. EFI/BIOS problems during the early boot
  4. "incompatibility" between your computer and this version of Linux. (That is, if someone thinks your computer is not to blame, they would have to blame the specific version of Linux :).

4. Why I blame the initramfs read from the USB

I found other unsolved mysteries described with the same error message and very similar conditions:

[1.81660] ---[end Kernel] panic - not syncing: VFS: unable to mount root fs on unknown-block(0,0).

Unfortunately, this isn't the real, specific error.

I have double-checked; Fedora-Workstation-Live 28 uses an initramfs. This is sometimes also called a type of initrd.

This error would be shown if you set up a boot with both a kernel and an initramfs, but some error prevents the initramfs being loaded.

For example, one way to trigger this error, would be if you pressed a special key at the boot menu to start a temporary edit of the boot options. In theory you might have started editing the boot options, and unintentionally removed an initrd option. So I have to mention this as a possibility :). Note this type of edit is temporary. So you can just boot again, and make sure you're not making an edit that disables the initramfs :).

In this case the kernel may "fall through" to an old-style boot without an initramfs, but then it doesn't have any "block device" that it was specified to mount as the root fs. "(0,0)" means "unknown"; this device number is never a valid block device.

But I don't think that's what you (and some others) did.

Therefore, I think there is probably a more specific error earlier in the boot process. Unfortunately, if there was an error message, it is possible you can't see it because it scrolled off the top of the screen, if there were too many messages since then :).

An image search for "unable to mount root fs on unknown-block(0,0)." shows that is very common for the kernel call trace to fill the screen. When this happens you cannot see if there is any previous error message.

I found an example of such an error, posted regarding a different Linux:


Initramfs unpacking failed: junk in compressed archive
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
--- [end Kernel] panic - not syncing: VFS: unable to mount root fs on unknown-block(0,0).

EDIT: called it :-). "Initramfs unpacking failed:" was the real error. "XZ-compressed data is corrupt" makes it clear the initramfs is not being read correctly from the USB

  • i added the pictures. Jul 4, 2018 at 7:53
  • @Faramarz have you tried the cmp command on a newly written Fedora Live USB, to verify that the data was written correctly to the USB? I just remembered this is probably really annoying to get right, so I have added an explanation in my answer. (Or, let me know if you followed alternative instructions, and they already had some sort of verification stage which passed OK).
    – sourcejedi
    Jul 4, 2018 at 9:38
  • yes i tried the cmp and got this: byte 1049089, line 3843 Jul 4, 2018 at 9:54
  • @Faramarz that's a failure. You really want to get some sort of successful verification of the USB (no differences, e.g. except that cmp should report that the USB is larger than ISO). The failure you show here actually looks suspiciously similar to what I remember if I replug (or reboot) after I wrote the USB, and Linux mounted it, causing it to change. Have you tried following the exact instructions I wrote in the re-revised version of my answer, please?
    – sourcejedi
    Jul 4, 2018 at 11:21
  • 1
    thanks for your help, cmp cleared me up that it was the USB so i did format it,it's all ok now. Jul 4, 2018 at 11:29

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .