0

I'm having issue with booting into my Fedora 19. First of all I have to mention that I "extracted" that system from virtual disk (simply DD the content of root and boot partition on physical disk), so there are plenty of things that could go wrong, but this appears not to be related problem. I've used live Ubuntu distribution to chroot into my Fedora system, used grub2-install and grub2-mkconfig to repair any grub errors that might appear, and it did work. Grub could find all kernels in boot partition and load it up, but then the problem appeared.

I'll use few pictures to demonstrate my situation. This is the error I get when booting into fedora.

Booting in

Now this is true, as blkid in dracut shell gives this. Those are my partitions on SATA HDD in notebook, normally referenced as sda, but I had another 2 USB devices plugged in, having system on one of them. The device with system is usually sdb and has both root and boot partition on it, so while grub must have known about it, it doesn't show up in this stage and it appears to me as kernel wasn't able to load them. Dracut blkid

To support the fact that those partitions really exist and are in good state, I ran live Ubuntu and called blkid from there. And here the partitions that are missing during booting popped up. Ubuntu blkid

So my question is, what could be possibly wrong with that Fedora and how to fix that? As I said I can chroot from Ubuntu so I can configure anything, if needed. Also, this problems appear only when I boot the "full" kernel. There's also option in grub to boot into rescue mode that works just fine and I can see my data in home folder (which is the same partition as root) there. I also include this information that describes my hardware configuration.

  • I'm not overly familiar with Fedora, but the problem appears to stem from missing access to USB Mass Storage devices. The corresponding kernel modules are probably missing from the initramfs or need to be explicitly activated. – Daniel B Mar 24 '14 at 14:23
  • what is the result of this: ls -l /dev/disk/by-uuid/ – cybernard Mar 25 '14 at 18:09
0

Solved by upgrading fedora 19 to 20 through live environment. It may be the case that fedora configured differently when installed inside virtual box and that information persisted somewhere. This upgrade has kept most of the data and programs intact, therefore for someone with such option it can be "good enough" solution.

| improve this answer | |
-1

Go into fstab and mtab and update the UUID. Your screen capture shows that the new and old have different UUID.

| improve this answer | |
  • Could you be, please, more specific about new and old UUID? I'm not able to see that mismatch. – Raven Mar 24 '14 at 14:13
  • I don't see any different UUIDs. In fact, the configuration is perfectly valid. – Daniel B Mar 24 '14 at 14:17
  • @Raven Long story short, even if you clone the new hard drive will have a different UUID. You need to change the UUID to match the new hard drive. – cybernard Mar 25 '14 at 0:41
  • @cybernard I'm aware of that, however mtab is created dynamically and fstab has correct UUIDs, so I can't really update anything because nothing's wrong there. – Raven Mar 25 '14 at 13:00

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.