Booting to Dracut (I trusted ChatGPT)

Pilow

@nuentes I explored my pool metadata backups, and I see a "part.1" file, that is a big XML of all the configuration of the pool

so yeah I don't think there is something else in here like your OS parameters, only pool config.

I could be wrong, but it's all I can see in here

AtaxyaNetwork

@nuentes You can reinstall without wiping the SR. Just plug the ISO, it will ask you if you want a clean install or a reinstall

Pilow

@AtaxyaNetwork yeah but if he doesn't have metadata backups, he will have SRs full of disconnected VDIs ? and the need to recreate each VM ?

AtaxyaNetwork

If I was in your place, I would do:

Disconnect all USB used as SR
Reinstall XCP-ng
if you have only a few VMs, my option would be just to redeploy XOA, REATTACH the SR (not create, REATTACH, be careful, a create will wipe your disk)
- Recreate VMs, attach the VDI, boot from here
if you have to many VM, directly after deploying XOA restore your metadata backup, it should be repluging the SR and create PDB at least (but it's been a while since I didn't use the metadata)

In any case, backup everything, especially the VDI (.vhd). If you have the VDI, you can work around with the rest

bvitnik

@nuentes metadata in this context is just XAPI database. In other words, it only contains information about your VMs, SRs, networks, pools etc. It does not contain anything system level. It is not a backup of the host system.

As far as I know, but someone from Vates can confirm, metadata backup functionality in XO is based on XAPI pool-dump-database command:

xe pool-dump-database file-name=dump.xml

There is some info about it here:

https://docs.xenserver.com/en-us/xenserver/8/dr/backup.html

P.S. I guess metadata backup is also XML just like XAPI state file (database). I don't know why JSON came to my mind regarding metadata backup.

Pilow

@bvitnik said in Booting to Dracut (I trusted ChatGPT):

P.S. I guess metadata backup is also XML just like XAPI state file (database). I don't know why JSON came to my mind regarding metadata backup.

Reply

perhaps because of other thread discussing metadatabackup.list in audit log

there is actually a bug there where the metadata is not only checked to be audited, but also completly dumped in JSON format.

AtaxyaNetwork

(BTW you don't have any backup from XOA ? If you have backup, you can just register a new XOA, connect to you remote and restore everything, it will be much simpler)

cg

@AtaxyaNetwork did you ever think about "upgrading" the system?
The installer should be able to detect and backup your current one, installl new and migrate all relevant data.
That should exclude whatever home-brew-fiddlydiddly you did to your current installation.
The reason you're seeing 2 almost identical partitions is exactly that: The way how upgrades work with XenServer/XCP-ng. One is your current system, the other one may contain a backup of a previous install (which can also be restored by the installer - if existing).

As it's been mentioned: Neither trust USB-storage nor any AI without knowing what they suggest you to do. But you may have learned your AI-lesson: It can help, but it can end with a big pile of sh*t if you don't know what it's suggesting you. It's more A than I.

nuentes

@cg I've definitely got some things to try. Thanks, guys. Just need to be cautious with how I proceed so I minimize any losses

nuentes

@AtaxyaNetwork @Pilow @bvitnik

Ok, knowing that the p2 partition was likely an old backup was exactly the breadcrumb that I needed. I confirmed via chroot and xsconsole that p2 was xcp-ng v8.2.1, and that p1 was v8.3. Then I was able to check the initrd files there. Namely I needed to see the updated dates and the kernel version. Thankfully, I saw initrd files on the backup that were the correct kernel and hadn't been disturbed. I then just cloned the initrd files from the backup partition to the p1 partition and BOOM. We booted right up.

Much appreciated for the assistance, everyone. I'll still need to figure out why my disks are disconnecting, but that will be another post for another day.