@techknowbabble said in GRUB waits for confirmation:

What did finally work was re-installing with the 'no serial' option and everything seems to be working as expected now. I only have a handful of XCP-NG installations under my belt but I wonder if this is a known bug or if anyone else has had a similar experience.

It's not something I've ever seen before and I've done quite a few installations but I can think of some possibilities as to why something like that might fix the problem. My best guess is that there's something built into, connected to, or otherwise in your system that looks like a serial port (maybe even a real serial port) that spits out a character or two into the system at boot time, confusing GRUB and stopping the normal boot process. The bad KVM I mentioned before was doing something like that, throwing a bogus keypress into the system at boot time.

@techknowbabble
All right, that's weird. Do you have any USB devices plugged into that host other than the keyboard or mouse and, if so, what are they? If you do, it might be possible that something reports itself as a type of HID connection and maybe the BIOS/UEFI in your system or GRUB is mistaking it for a keyboard. I know some UPS units could do that (though I've never seen it myself).

@techknowbabble said in GRUB waits for confirmation:

I have tried fresh installs of 8.2.1 and 8.3 and it will boot but not until I select an option from the GRUB menu. I am using UEFI without secure boot. There is an asterisk next to the 'XCP-NG" option which I believe confirms it is the default option, but GRUB will not start it until I manually select it.

Is your system connected to any sort of KVM switch? I had a weird problem where sometimes systems connected to a particular KVM switch would do this if they were rebooted when they weren't the system the KVM was set to view. It would never happen if they were rebooted while being viewed by the KVM, only if they weren't and not always then. The symptom you're describing sounds exactly the same as what happened to me.

Installed and seems to be working well on my test systems.

@gduperrey, I suspected that was the case after seeing that message but wanted to make sure. Thanks!

@stormi said in XCP-ng 8.2 updates announcements and testing:

@JeffBerntsen Do you have XOSTOR on the pool?

Not yet, but was planning to add it to this test pool so thought I should downgrade beforehand. Does that particular patch only apply to systems with XOSTOR already installed?

@gduperrey, that doesn't seem to work for me. I receive an error from yum:

No Match for available package: http-nbd-transfer-1.3.0-1.xcpng8.2.x86_64
Nothing to do

Seems to be working well on my test servers.

This seems to be working well for me too.

@Danp You're right, I missed the question mark on it when I tried it before. With the question mark, it works. Thank you for your help.

@Danp I've tried that and it doesn't seem to work. Entering hasVendorDevice into the filter box whether followed with nothing, with :true or :false, leaves the filtered VM list completely empty. I'm running on xoa updated to the latest stable channel version, 5.99.1.

I'm trying to filter the VM list to show only Windows servers that are set to receive drivers via Windows update and don't seem to be able to do it. As far as I know, the property is called hasVendorDevice but using either hasVendorDevice:true or hasVendorDevice:false ends up showing no VMs at all? Am I doing something wrong and, if so, what or is it just not possible to filter on this? I'm also trying to filter based on the secure boot setting and having the same problem with that.

Any help would be greatly appreciated.

@bleader They're installed and running well on my test lab systems.

@OhSoNoob I've used XOSTOR on top of MDRAID and it seemed to work well for me during my testing. I ran tests of it on top of MD RAID 1, 5, and 10 (MDRAID's "RAID 10" which isn't really RAID 10) and had good luck with it. The XOSTOR is really adding a second layer of redundancy at that point, similar to MDRAID 5+1 builds so is almost overkill. Almost.

Where I see the most benefit from XOSTOR on MDRAID would be on top of RAID 10 or RAID 0 arrays. Depending on the speed of your drives, you might get some benefit from the increased read speed (and read/write speed for RAID 0). In addition, RAID 10 would give you some additional redundancy so that losing a drive wouldn't mean the loss of that node for XOSTOR's purposes, possibly making recovery easier.

The ability for some redundancy might also be useful for a stretched cluster or some other situation where your network links between XOSTOR nodes isn't as fast as it should be; The ability to recover at the RAID level might be much faster than recovering or rebuilding an entire node over a slow link.

@ronan-a, I'm not sure if you remember, but the very first test of XOSTOR I ran, shortly after it was introduced,, were on top of RAID 10 arrays. I kept that test cluster alive and running until equipment failure (failed motherboards, nothing related to XOSTOR or MDRAID) forced me to scrap it. I had similar teething pains to others while XOSTOR was being developed and debugged during the test phase, but nothing related to running on top of MDRAID as far as I could tell.

@stormi Not a problem. I just wanted to make sure I hadn't done something wrong. As it is, the system is working with all of the updates but that one in place.

Only one of my two systems will take the complete update, but that one is working just fine.

The other which I had used in the past as a test server for XOSTOR will not install the sm-2.30.8-12.1.xcpng8.2.x86_64 package looking for a dependency on sm-linstor and not finding it.

@flibbi, @olivierlambert RAID shouldn't be problem for XOSTOR. During some of my testing shortly after the preview was released, I was running it on software RAID 10 arrays on each of my test servers. As long as the RAID isn't some sort of "fake RAID" and is done in hardware, it should work fine.

@stormi None of the other things I tried fixed the problems with left over update artifacts but running a normal yum update after this did. Thanks!

@bleader Seems to be running just fine on my test servers as well.

They're running without problems for me on my test systems