Dracut error with CentOS 7 in a virtual machine
Solved
guillaumegilbertsoucy
Posted messages
369
Status
Member
-
guillaumegilbertsoucy Posted messages 369 Status Member -
guillaumegilbertsoucy Posted messages 369 Status Member -
Hello everyone,
I have a dracut error on a CentOS 7 virtual machine when it boots. Initially I converted a disk image .vmdk to .qcow2, but the same startup error occurs even when the .vmdk is used as is, i.e., without converting it to .qcow2.
Here is a screenshot of the error in the Proxmox console:
[image link]
In a thread on Proxmox forums, it is suggested to run the command modprobe virtio_scsi in the console, but that returns another error:
[image link]
Firstly, I converted the disk image from .vmdk to .qcow2 following this tutorial.
Given the failure, I removed the VM and recreated it using the disk image as-is without conversion. The same problem with the same error message reoccurs during boot of this VM.
The image provider, StorageMadeEasy, will not be able to offer technical support because the disk image used is the “community” version of their software and is provided for free as-is.
The operating system is CentOS 7 and here are the VM details below:
[image link]
If more information or details are required, please let me know and I will provide them gladly.
I appreciate the help in advance,
Sincerely,
Guillaume
I have a dracut error on a CentOS 7 virtual machine when it boots. Initially I converted a disk image .vmdk to .qcow2, but the same startup error occurs even when the .vmdk is used as is, i.e., without converting it to .qcow2.
Here is a screenshot of the error in the Proxmox console:
[image link]
In a thread on Proxmox forums, it is suggested to run the command modprobe virtio_scsi in the console, but that returns another error:
[image link]
Firstly, I converted the disk image from .vmdk to .qcow2 following this tutorial.
Given the failure, I removed the VM and recreated it using the disk image as-is without conversion. The same problem with the same error message reoccurs during boot of this VM.
The image provider, StorageMadeEasy, will not be able to offer technical support because the disk image used is the “community” version of their software and is provided for free as-is.
The operating system is CentOS 7 and here are the VM details below:
[image link]
If more information or details are required, please let me know and I will provide them gladly.
I appreciate the help in advance,
Sincerely,
Guillaume
7 answers
-
Hello,
Question like this, is it necessary to have root account access of the image in order to execute the maneuvers proposed in the links you mentioned above?
Thank you,
Guillaume -
Hello,
Message #5
Indeed, or perhaps something we haven't understood. I invite you to look at:
In particular, two sections are worth reading:
If you're blocked, you can also ask the dracut maintainers directly via this link. In any case, it's not normal that it crashes just by launching their image.
Message #6
Compared to a standard machine, indeed it seems a bit light, since the source of/
is not specified... but it might be normal indracut
. If needed you can see what is mounted with the commandmount
.
Message #7
Yes, you need to be root, but first check their documentation.
Good luck-
Hello, Just one thing, I won’t be able to elevate to root in this image because it is the “community” version; to get root access you must subscribe to the “Enterprise” version, which is paid. The reason I’m making this comment is that if root access is required at some point in the process, it would block my path since, as I mentioned, there is no root access for the “community” version. I will still take the time to read the tutorial you took the time to link to. Thank you, Guillaume
- You can work around the problem without being root, because from grub you can change the root device (press e to edit grub entries). In their documentation, they have an entire section explaining what the root device is (it's basically the partition that corresponds to /), the two ways to refer to it (either by its UUID or by the device associated with the partition, e.g. /dev/sda2 depending on your partitioning). According to their documentation, they don’t have /etc/default/grub and they patch directly /boot/grub2/grub.cfg (see previous messages; in theory the first is used to generate the second). To modify that file (in particular to fix the UUID) you’ll need to be root. It would also be worth seeing if you can find functional images...
-
-
Hello everyone,
Due to a lack of time, I have not been able to devote much time to this problem. But it is progressing, slowly but surely.
I am sorry for this situation. More time will be dedicated in January 2022.
Thank you,
Guillaume -
Hello,
Thank you for copying and pasting the text rather than taking screenshots (in MS-DOS commands, this can be done via the icon at the top left of the window), it will be more convenient for everyone.
Given the failure, I therefore deleted the virtual machine and recreated it using the disk image as-is without converting it. The same problem with the same error message recurred when launching this virtual machine.
The problem is therefore not related to the format of the VM image nor to the conversion you did.
If you read this discussion, you can see that it is probably GRUB that is misconfigured on the image you retrieved, which explains why the disk on which the Linux system is supposed to boot is not found. The repair procedure is indicated in this same link; can you try it.
Good luck -
Okay, I’ll try that and I’ll post the results here. Thanks!
-
Hello,
I tried to do what the tutorial says but this is the result for every command I send to the console:
Sorry for the screenshots, I can't copy-paste from the KVM console in Mozilla Firefox.
Also, the image was updated by the editor but the new version seems to have the same problem.
Thank you,
Guillaume-
It is weird, according to this page and this page, the file /etc/default/grub should exist on CentOS. I invite you to search with find and grep where it could be: find /etc | grep -i grub Otherwise that may mean the grub configuration was written manually and resides purely in /boot/grub. Nowadays that is no longer the case: normally one uses grub-mkconfig which is based on /etc/default/grub to generate the files contained in /boot/grub. You can probably find the path to this file by looking at the header of /boot/grub/grub.cfg. Example (under Debian): (mando@silk) (~) $ head /boot/grub/grub.cfg # # DO NOT EDIT THIS FILE # # It is automatically generated by grub-mkconfig using templates # from /etc/grub.d and settings from /etc/default/grub # # ### BEGIN /etc/grub.d/00_header ### if [ -s $prefix/grubenv ]; then set have_grubenv=true
- A question: If my /etc/fstab only contains that, is it normal? (my apologies for the screenshot):
The fstab file isn’t like on my other machines, it’s missing some lines...
and also, with the "rescue" mode it boots.
In the link, is the person in the "rescue" mode? Because I didn’t have a[root@srv ~]
prompt in "emergency" mode.
Thanks,
Guillaume
-
-
But how can they have published an image with defects? That’s not very responsible of them...
I’m taking a look at the information you posted above. But to be honest, I’ve never really “played” with the grub, so it’s really tricky for me. Normally everything works without touching that. But there’s a first time for everything!
Have a good day!
Guillaume
