dracut-initqueue timeout please help

andrewvodonnell

New Member
Oct 31, 2024
5
0
1
I've got a vm that when it starts goes to dracut-initqueue timeout and i'm a bit fuzzy on the technical side of this on what to do to resolve this issue. If anyone can help me resolve this i'd greatly appreciate it. Our vendor that provided the OVA file only supports us if we are using vSphere (previously ESXi). Install is pretty simple under the old ESXi (shows you how long it's been since we had to set up a box). Background - box is a standalone server once the VM is running for a building automation system that basically turns this box into a large controller. We are just having a few small issues as we move over to proxmox on getting the first one going. We have a dozen more to move over to proxmox once we resolve this issue. All installs are identical so if we can resolve this it becomes a cookie-cutter setup going forward. Thank you so much for any help you can give me.
 
I had a similar issue migrating a vm from vSphere to proxmox, in my case it was a problem with the virtio drivers, as the disk was configured as SCSI using the virtio scsi single controller.

Have you tried editing the disk and see if it boots as ide/sata?

If you have access to a ESXi host or vSphere environment you can also boot the server there, and then verify if the virtio drivers are included in the kernel and in the boot temporary filesystem (I found this link helpful https://www.tencentcloud.com/document/product/213/9929 ) and also possibly add the drivers using dracut

dracut --add-drivers "virtio_balloon virtio_ring virtio_input virtio_pci virtio virtio_blk virtio_net virtio_scsi" --force

In case you cannot login on the server, playing around with the controller/disk might help in getting the server to boot, but performances might suffer, in which case it might be a good idea to ask the vendor to possibly include virtio drivers/KVM support, as you will possibly not be the only customer considering a migration from vSphere to Proxmox
 
  • Like
Reactions: ericdaltman
I had a similar issue migrating a vm from vSphere to proxmox, in my case it was a problem with the virtio drivers, as the disk was configured as SCSI using the virtio scsi single controller.

Have you tried editing the disk and see if it boots as ide/sata?

If you have access to a ESXi host or vSphere environment you can also boot the server there, and then verify if the virtio drivers are included in the kernel and in the boot temporary filesystem (I found this link helpful https://www.tencentcloud.com/document/product/213/9929 ) and also possibly add the drivers using dracut

dracut --add-drivers "virtio_balloon virtio_ring virtio_input virtio_pci virtio virtio_blk virtio_net virtio_scsi" --force

In case you cannot login on the server, playing around with the controller/disk might help in getting the server to boot, but performances might suffer, in which case it might be a good idea to ask the vendor to possibly include virtio drivers/KVM support, as you will possibly not be the only customer considering a migration from vSphere to Proxmox
I just wanted to thank you as I was dealing with this as well and figured it was a missing driver in the initramfs, but wasn't sure what to include. I ssh'd into the host, mounted and chroot'd into the VM's drives, and performed the dracut I had already built, including the --add-drivers above and it solved this for me. I have two more VMs to import from VirtualBox and I imagine I'll be doing this twice more.

Note for those who read this and think this is the solution for them, because the nature of chroot don't forget to bind mount /sys, /run, /proc, and /dev, then chroot, and when using the dracut command you will likely need to include the path to the initramfs image file and then the kernel version after.

This was my command, for a real world example (note it has my file includes that I was using for troubleshooting):

Bash:
dracut --add-drivers "virtio_balloon virtio_ring virtio_input virtio_pci virtio virtio_blk virtio_net virtio_scsi"  --include /usr/bin/find /usr/bin/find --include /usr/bin/lsblk /usr/bin/lsblk   --force /boot/initramfs-5.14.0-503.22.1.el9_5.x86_64.img 5.14.0-503.22.1.el9_5.x86_64

Again, thanks for saving me from further headache.
 
  • Like
Reactions: lrizzo
Little update from my side:

It is working like that. Just some additional point.
On target VM to migrate:
  1. Adjust the initial RAM Disk as in your link you provided with
    Code:
    mkinitrd
  2. Adjust the dracut boot process
    Code:
    dracut --add-drivers "virtio_balloon virtio_ring virtio_input virtio_pci virtio virtio_blk virtio_net virtio_scsi" --force
  3. Shutdown the VM (Full process described here)
  4. Ensure enough Space is available on the target Proxmox host
  5. Migrate the OVF and Disk Files with the "ovftool"
  6. Import it via qm Command
    Code:
    qm importovf
  7. My additional Point: Adjust the VM in Proxmox as proposed in the recommendations of the Proxmox Migration Guide.
    BUT, something I encountered, which is critical and not happening automatically or is mentioned: Adjust the OS Type in the VM Options. It might be that it resides by default on "other" which is leading to a faulty start as well. In my case I adjusted it to Linux 6.x
I think this thread can be marked as solved.
 
I could not resolve this issue by adding drivers to the dracut boot process. After migrating my CentOS 7 VM from VMware to Proxmox, I had to change the drive connection type from a SCSI controller to IDE:

In Proxmox (after the VM has been migrated from VMware/ESXi):
1) Make sure the VM is powered off

2) Change SCSI controller to "VirtIO SCSI single" (other values may work, depending on your setup. This is what worked for me in this case)

3) On PVE host CLI:
qm config (VMID) (EX: qm config 123)
-Take note of disk name

4) In Proxmox GUI, detach disk:
VM-->Hardware-->Hard Disk-->Click "Detach"

5) Back in PVE host CLI:
qm set VMID -ide0 DISKNAME (EX: qm set 123 -ide0 local-lvm:vm-123-disk-0)

6) Run "qm config (VMID)" to see reconfigured disk:
qm config (VMID) (EX: qm config 123)

7) Boot machine up

Once I did these steps (I did not do any dracut boot process manipulations with this attempt), my CentOS 7 VM booted up with no problems. My confusion as to why this solution works is because VMware tells me the machine is configured with a SCSI controller, and Promox assigns it a SCSI controller as well. I can't find anything in my virtual config on either side that suggests this needs an IDE controller. There are some unknowns here, this is a really old VM that we believe was created from an OVA. However no one documented how they created this machine, nor can anyone remember who actually built it, so there very well may have been something done on original VM creation that necessitated this IDE change. Regardless, the steps above is how I was able to remedy this. I hope someone finds this useful in the event the dracut process doesn't work.

This site was extremely helpful with this resolution:

https://vormox.com/blog/how-to-choo...m-in-proxmox-ve-ide-vs-sata-vs-scsi-vs-virtio