Kernel panic while installing Fedora 28

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
1
down vote

favorite












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]







share|improve this question

















  • 3




    How did you create the install media?
    – kemotep
    Jul 3 at 17:35






  • 1




    @kemotep with dd command, iso file.
    – Faramarz
    Jul 3 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 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.
    – Faramarz
    Jul 3 at 19:40














up vote
1
down vote

favorite












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]







share|improve this question

















  • 3




    How did you create the install media?
    – kemotep
    Jul 3 at 17:35






  • 1




    @kemotep with dd command, iso file.
    – Faramarz
    Jul 3 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 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.
    – Faramarz
    Jul 3 at 19:40












up vote
1
down vote

favorite









up vote
1
down vote

favorite











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]







share|improve this question













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]









share|improve this question












share|improve this question




share|improve this question








edited Jul 4 at 8:46
























asked Jul 3 at 17:34









Faramarz

205




205







  • 3




    How did you create the install media?
    – kemotep
    Jul 3 at 17:35






  • 1




    @kemotep with dd command, iso file.
    – Faramarz
    Jul 3 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 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.
    – Faramarz
    Jul 3 at 19:40












  • 3




    How did you create the install media?
    – kemotep
    Jul 3 at 17:35






  • 1




    @kemotep with dd command, iso file.
    – Faramarz
    Jul 3 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 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.
    – Faramarz
    Jul 3 at 19:40







3




3




How did you create the install media?
– kemotep
Jul 3 at 17:35




How did you create the install media?
– kemotep
Jul 3 at 17:35




1




1




@kemotep with dd command, iso file.
– Faramarz
Jul 3 at 17:43




@kemotep with dd command, iso file.
– Faramarz
Jul 3 at 17:43




1




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 at 18:42





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 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.
– Faramarz
Jul 3 at 19:40




@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.
– Faramarz
Jul 3 at 19:40










2 Answers
2






active

oldest

votes

















up vote
1
down vote



accepted










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 :-(.



    https://docs.fedoraproject.org/f28/install-guide/install/Preparing_for_Installation.html



  • 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.



But you might also want to test the USB keeps its data correctly after it is removed and loses power. In this case you need 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:



  • Fedora Live Usb won't boot

  • I can't make a bootable USB [of Fedora 24]...

  • kernel panic -not syncing VFS: unable to mount root fs on unknown-block(0,0) on Fedora 22 installation


[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:



https://bbs.archlinux.org/viewtopic.php?id=220178



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






share|improve this answer























  • i added the pictures.
    – Faramarz
    Jul 4 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 at 9:38










  • yes i tried the cmp and got this: byte 1049089, line 3843
    – Faramarz
    Jul 4 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 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.
    – Faramarz
    Jul 4 at 11:29

















up vote
0
down vote













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.






share|improve this answer





















  • 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 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 at 11:57











Your Answer







StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);








 

draft saved


draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f453272%2fkernel-panic-while-installing-fedora-28%23new-answer', 'question_page');

);

Post as a guest






























2 Answers
2






active

oldest

votes








2 Answers
2






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
1
down vote



accepted










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 :-(.



    https://docs.fedoraproject.org/f28/install-guide/install/Preparing_for_Installation.html



  • 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.



But you might also want to test the USB keeps its data correctly after it is removed and loses power. In this case you need 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:



  • Fedora Live Usb won't boot

  • I can't make a bootable USB [of Fedora 24]...

  • kernel panic -not syncing VFS: unable to mount root fs on unknown-block(0,0) on Fedora 22 installation


[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:



https://bbs.archlinux.org/viewtopic.php?id=220178



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






share|improve this answer























  • i added the pictures.
    – Faramarz
    Jul 4 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 at 9:38










  • yes i tried the cmp and got this: byte 1049089, line 3843
    – Faramarz
    Jul 4 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 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.
    – Faramarz
    Jul 4 at 11:29














up vote
1
down vote



accepted










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 :-(.



    https://docs.fedoraproject.org/f28/install-guide/install/Preparing_for_Installation.html



  • 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.



But you might also want to test the USB keeps its data correctly after it is removed and loses power. In this case you need 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:



  • Fedora Live Usb won't boot

  • I can't make a bootable USB [of Fedora 24]...

  • kernel panic -not syncing VFS: unable to mount root fs on unknown-block(0,0) on Fedora 22 installation


[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:



https://bbs.archlinux.org/viewtopic.php?id=220178



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






share|improve this answer























  • i added the pictures.
    – Faramarz
    Jul 4 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 at 9:38










  • yes i tried the cmp and got this: byte 1049089, line 3843
    – Faramarz
    Jul 4 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 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.
    – Faramarz
    Jul 4 at 11:29












up vote
1
down vote



accepted







up vote
1
down vote



accepted






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 :-(.



    https://docs.fedoraproject.org/f28/install-guide/install/Preparing_for_Installation.html



  • 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.



But you might also want to test the USB keeps its data correctly after it is removed and loses power. In this case you need 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:



  • Fedora Live Usb won't boot

  • I can't make a bootable USB [of Fedora 24]...

  • kernel panic -not syncing VFS: unable to mount root fs on unknown-block(0,0) on Fedora 22 installation


[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:



https://bbs.archlinux.org/viewtopic.php?id=220178



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






share|improve this answer















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 :-(.



    https://docs.fedoraproject.org/f28/install-guide/install/Preparing_for_Installation.html



  • 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.



But you might also want to test the USB keeps its data correctly after it is removed and loses power. In this case you need 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:



  • Fedora Live Usb won't boot

  • I can't make a bootable USB [of Fedora 24]...

  • kernel panic -not syncing VFS: unable to mount root fs on unknown-block(0,0) on Fedora 22 installation


[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:



https://bbs.archlinux.org/viewtopic.php?id=220178



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







share|improve this answer















share|improve this answer



share|improve this answer








edited Jul 4 at 11:29


























answered Jul 3 at 20:49









sourcejedi

18k22375




18k22375











  • i added the pictures.
    – Faramarz
    Jul 4 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 at 9:38










  • yes i tried the cmp and got this: byte 1049089, line 3843
    – Faramarz
    Jul 4 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 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.
    – Faramarz
    Jul 4 at 11:29
















  • i added the pictures.
    – Faramarz
    Jul 4 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 at 9:38










  • yes i tried the cmp and got this: byte 1049089, line 3843
    – Faramarz
    Jul 4 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 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.
    – Faramarz
    Jul 4 at 11:29















i added the pictures.
– Faramarz
Jul 4 at 7:53




i added the pictures.
– Faramarz
Jul 4 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 at 9:38




@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 at 9:38












yes i tried the cmp and got this: byte 1049089, line 3843
– Faramarz
Jul 4 at 9:54




yes i tried the cmp and got this: byte 1049089, line 3843
– Faramarz
Jul 4 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 at 11:21





@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 at 11:21





1




1




thanks for your help, cmp cleared me up that it was the USB so i did format it,it's all ok now.
– Faramarz
Jul 4 at 11:29




thanks for your help, cmp cleared me up that it was the USB so i did format it,it's all ok now.
– Faramarz
Jul 4 at 11:29












up vote
0
down vote













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.






share|improve this answer





















  • 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 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 at 11:57















up vote
0
down vote













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.






share|improve this answer





















  • 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 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 at 11:57













up vote
0
down vote










up vote
0
down vote









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.






share|improve this answer













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.







share|improve this answer













share|improve this answer



share|improve this answer











answered Jul 4 at 11:26









Faramarz

205




205











  • 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 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 at 11:57

















  • 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 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 at 11:57
















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 at 11:43





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 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 at 11:57





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 at 11:57













 

draft saved


draft discarded


























 


draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f453272%2fkernel-panic-while-installing-fedora-28%23new-answer', 'question_page');

);

Post as a guest













































































Popular posts from this blog

How to check contact read email or not when send email to Individual?

Displaying single band from multi-band raster using QGIS

How many registers does an x86_64 CPU actually have?