John's Blog

After upgrading from Fedora 21 to Fedora 22 I experienced a kernel panic on booting into the new, 4.0.2 kernel with the message given in the title "VFS Unable to mount root FS on unknown-block(0,0)". Long story short - looking into /boot there was the vmlinuz kernel, vmlinuz-4.0.2-300.fc22.x86_64 , but no corresponding initramfs-4.0.2-300.fc22.x86_64.img file. Also in the grub.cfg stanza there was a missing reference to the .img file i.e.    initrd16 /initramfs-4.0.2-300.fc22.x86_64.img was missing. Again, in the interest of brevity, I ran dracut manually on the 4.0.2 kernel and it errored - complaining about "no module bootchart found". (Bootchart is a package I had installed previously that attempts to measure or profile time spent during booting - I'm assuming that F22 dracut does not have the needed support.) Fortunately Dracut has an option to ignore arbitrary modules e.g. bootchart with the parameter -o. So the fix was ultimately to do somet...

As indicated now in the title of Redhat Bugzilla 969648 the problem is the "data=writeback" parameter in /etc/fstab. Fedup and Fedora 19 have a problem with this particular setting.  I have two fedora machines - a desktop and a laptop. During the last upgrade cycle, Fedora 17-->18, the desktop upgraded without any problem whatsoever. On the laptop, I had managed to shoot myself in the foot due to basically having some parts of my kernel boot commandline that were present in grub.cfg but not in /etc/default/grub. (These were the parts that blacklisted nouveau so that the nvidia binary driver could run). At the end of the fedup procedure I had run     grub2-mkconfig -o /boot/grub2/grub.cfg as instructed and this wiped out the parts of my command line that were needed to run the nvidia driver and due to that I had all sorts of problems figuring out the problem. Of course once the problem was diagnosed the fix was relatively easy. This time around, in going from 1...