SSD screws up Proxmox boot

Without knowing any specifics, It could be a number of things.
  • The BIOS may have that ssd higher in the boot order than your proxmox. And it is trying to boot a bad OS
  • The SSD could be in your /etc/fstab and causing errors
  • Your 2 TB SSD still has old filesystem signatures, partitions, or metadata (from the troubleshooting days) that Proxmox/Debian automatically scans, mounts, or tries to import (via udev/udisks, blkid, ZFS, LVM, etc.). That scanning causes the host to “crap out” as soon as the drive is detected.
If you don't need what is on the SSD, you may want to put it in another computer, and wipe it.
 
jaminmc said:
Without knowing any specifics, It could be a number of things.
  • The BIOS may have that ssd higher in the boot order than your proxmox. And it is trying to boot a bad OS
  • The SSD could be in your /etc/fstab and causing errors
  • Your 2 TB SSD still has old filesystem signatures, partitions, or metadata (from the troubleshooting days) that Proxmox/Debian automatically scans, mounts, or tries to import (via udev/udisks, blkid, ZFS, LVM, etc.). That scanning causes the host to “crap out” as soon as the drive is detected.
If you don't need what is on the SSD, you may want to put it in another computer, and wipe it.
Click to expand...
  • I made sure that the drive was not in the bios boot order at all
  • I did not see anything in /etc/fstab that specifically referenced this device but I don't know what I am doing
  • The first time I had issues I tried wiping the SSD
fstab
Code: 
/dev/pve/root / ext4 errors=remount-ro 0 1
/dev/pve/swap none swap sw 0 0
proc /proc proc defaults 0 0
 
Last edited:
Is the drive an NVMe and are you using PCI(e) passthrough (for other) devices? Adding (or removing) PCI(e) devices can change the PCI ID of the other devices. This can break an existing setup when you add the drive. Also, make sure the drive is in a separate IOMMU group.
Is the drive connected via SATA and did you do a PCI(e) passthrough of a SATA controller? Make sure no other drives are connected to that same controller and make sure there are no other devices in the same IOMMU group.
Or are you trying to do disk passthrough? Make sure to use /dev/disk/by-id or something instead of /dev/sdb as those are not stable.
 
leesteken said:
Is the drive an NVMe and are you using PCI(e) passthrough (for other) devices? Adding (or removing) PCI(e) devices can change the PCI ID of the other devices. This can break an existing setup when you add the drive. Also, make sure the drive is in a separate IOMMU group.
Is the drive connected via SATA and did you do a PCI(e) passthrough of a SATA controller? Make sure no other drives are connected to that same controller and make sure there are no other devices in the same IOMMU group.
Or are you trying to do disk passthrough? Make sure to use /dev/disk/by-id or something instead of /dev/sdb as those are not stable.
Click to expand...
The drive is in fact an NVMe drive.

"Adding (or removing) PCI(e) devices can change the PCI ID of the other devices. This can break an existing setup when you add the drive. Also, make sure the drive is in a separate IOMMU group."

Not sure how I can fix any of that.
 
Jay Hova said:
The drive is in fact an NVMe drive.

"Adding (or removing) PCI(e) devices can change the PCI ID of the other devices. This can break an existing setup when you add the drive. Also, make sure the drive is in a separate IOMMU group."

Not sure how I can fix any of that.
Click to expand...
Don't (auto) start any VMs that use PCI(e) passthrough. Look at the new PCI IDs and in which IOMMU groups they now are. Adjust all the passthrough mappings for all existing VMs accordingly.
 
That will indeed prevent VMs from starting when PCI IDs or IOMMU grouping changes. And you have one place to fix the mappings when you add/enable or remove/disable PCI(e) devices (on-board or add-in).
 
You must log in or register to reply here.
Top Bottom
Back