Bug #4222
closed
Update to 2.2 RC breaks domU
0%
Description
By doing an upgrade to nightly RC build for 2.2 from a working 2.1.5 install, it breaks it in Citrix XenServer. 2.2 sees the virtual disk from XenServer as ada0 instead of ad0 now.
This issue is reproducible on both Creedence (XS6.5) and XS6.2.
Listed by other user in the ML, and I commented on the forum as well on how to repair it. It is a simple fstab modification.
fix is here: https://forum.pfsense.org/index.php?topic=86827.msg476281#msg476281
I was able to get it to reboot cleanly as well by editing fstab from command line while upgrade was in progress.
Updated by Jim Pingle over 10 years ago
- Status changed from New to Rejected
Already documented. It's a Xen/PVHVM thing we can't control.
Updated by Jim Pingle over 10 years ago
To elaborate on that a little, the main problem with the disk is that the PVHVM drivers in FreeBSD apparently do not respect kern.cam.ada.legacy_aliases and so they do not setup the adX links that true ATA disks receive to preserve backward compatibility. Feel free to report it upstream to FreeBSD.
Updated by Douglas Haber over 10 years ago
Theoretically, could a hook for the referenced shell script be added into the pfSense upgrade process? Or even a sed for a fstab?
I lack a deep understanding on the upgrade process still, trying to learn it further.
Updated by Jim Pingle over 10 years ago
In theory it is possible but given the wide range of disks that have been setup over the years, it is not yet a process we trust implicitly to function 100% of the time for every disk. The script displays the potential changes and requests confirmation that the changes are OK/sane, it's still possible that for one reason or another the process would fail and require manual intervention. Better to fail in a predictable way (having to edit fstab) vs failing in an unpredictable way (mangled fstab)
Updated by Douglas Haber over 10 years ago
Maybe a hook should be added then in the web UI to say, "hey, Xen detected, please make sure you checked (this note) prior to performing the upgrade"?
Dmesg reports "ACPI APIC TABLE: <Xen HVM>" and "acpi0: <Xen> on motherboard", even in 2.1.5, so a quick check of that also may be helpful? Or maybe there is an even better way to evaluate if it's Xen, which I can look into..
Updated by Chris Buechler over 10 years ago
Douglas Haber wrote:
Maybe a hook should be added then in the web UI to say, "hey, Xen detected, please make sure you checked (this note) prior to performing the upgrade"?
We can't go back in time and add code to people's existing installs. It would only run code from the upgraded system after the upgrade is complete and it's too late at that point.